contradicting で矛盾を指摘していることを示せる？
https://youtu.be/S2DeIIJF1DA
10:10- 背景
- アプリケーションレベル・ファイアウォールで監視とある
- ファイアウォールでは、通信をとめるところまで
- 操作ログは聞いたことがない
- 問題点
- 全体図
- 説明が長い
- 似たような図が二つある。一つでなんとかならないか。
- 実装の方は図ではなく文章だけでいいかもしれない 💭
- 「遅延解析」が図中に出てこない
- パケットを流しながら解析するという話。モジュールの話は、よい。パケットや鍵の流れを説明されているとよい。
- rustls について
- 難しいことをやったことを言ってほしい
- 何が問題だったのか。何が難しかったか。
- 実装のところには答えだけが書いてある。
- 鍵をどう取り出すのか。
- 対話的にルールを追加できることを書ければよかったが
- 性能評価
- 復号動作の確認
- 論文ならいいけどスライドだとちょっとわかりにくいかも。
- ブラウザのフォームに入れた例とか
- 先にそのような例をスクショと共に出して、そのアンサーとして復号動作のことを書く
- 復号がわかった後で、機能評価。単なる実験と評価だけだと、評価の方が重要、重たい。結果のもとで評価がある。復号できたという実験をして、機能評価として復号ができていることを述べる。その後、性能について軽く触れる。
- 発表すると、すぐにそっちに引きづられて質問される。情報科学類の学生・教員もそうだが、スピード狂なのでそちらに引きづられる。注意して性能の部分をいかに弱めて発表する。他のところを見てほしい。性能に関する質疑がこないようにすることが目標。本研究は HPC ではないので、性能を弱く言う。
- 方法としてはいろいろある。
- 性能は大丈夫でした程度の気持ちにしたい。
- 強弱をつける。
- 関連研究
- メモ
- 全体図について
- ✅ VMM の略称を図中に入れる
- ✅ 遅延解析を図中に入れる。通信内容検査器の近くに書く
- ✅ パケットと鍵の流れに焦点を当てて、そこに関わってくるモジュールの説明があるとよい。現状の説明でもよくなっているような気はする。
- そのままで、パケットフィルタ制御プログラムとかを繰り返し言うのをやめた。代わりにユーザ空間と言った。
- rustls への変更について
- rustls は通常、TLS 通信をするために利用されるライブラリである
- 通信で利用されるパラメータ等は TLS handshake 時に通信相手と交換される。その際、各エンドポイントは client_random などを生成する。しかしながら、今回は既に確立された TLS 接続に関する復号を行うため、復号時に利用できる共通鍵を rustls が算出する際には、すでに rustls が生成してしまった別のパラメータを用いることはできない。したがって、復号すつ通信に対応するパラメータを外側から注入する必要がある。このとき、master_secret も同様である。
そこで、本研究ではキャプチャしたパケットから TLS 接続のパラメータの一部を抽出し、master_secret についてはアプリケーションから SSLKEYLOGFILE フォーマットで記述させ、それをパケットフィルタ制御プログラムから取得するようにした。 - 上記のことを行うと、rustls が予期した接続のものとは異なるパラメータが注入されることから、真正性と完全性のチェックに失敗する。ここで、両者のチェックは本来アプリケーションによって行われるものであり、本ファイアウォールによる検証は不要である。したがって、これらの処理を削除する。
- 性能評価の図は必要ないかも。文章だけでリモートホスト 1、2 の説明をしてしまう？
- 性能は利用に耐えうることを軽く触れるようにしたい
- スライドを 2 枚に収めたい
- CPU の種類を書く
- 関連研究で IDS などについて触れ、本研究の優位性を示す
cyanolupus 9:55- p.2 ロールバック攻撃に対する脆弱性、なぜある
- p.3 失ってしまうので保存することが難しいことを言う
- p.4 何の状態？
- p.5 利便性や維持コストの問題、具体的になにかあるか
- pp.12-13 tamago, Tamago の表記揺れ
- p.15 コマンドにアノテーションを付けるといいかも
- Keynote で作っているなら行間または段落間を狭めるといいかも
- p.19 ページ番号が citation と被ってる
- p.17 Intel ME の citation は p.19 で初出？
- yas
azarashi 16:55- p.3 Keynote で作っているなら行間または段落間を狭めるといいか
- p.6 ブラウザ以外の usage は削ってもよい
- p.8 図中の WASI について説明がなかった、p.6 ではなくここで WASI の説明をしていいのかも
- p.12 実装の解決策について述べている流れは参考にしたい 💭
- p.15 引数の型 ciovec_array の意味をスライドにも書いてほしいかも
- p.16
- ページ番号に図が overwrap してる
- マーシャルは Base64 してる？っぽいけどそれを書いてもいいかも
- p.19
- p.22
- 図が小さい
- caption をつける
- ユーザの UID/GID に対応するセッションプロセスによるアクセス制御が働いていることの検証がほしい
- p.23 図中の赤い点線の意味
- yas
- 白地のスライドでは黒地に白のターミナルは見辛いかもしれない
shuntaro 15:00 程度- p.2
- 中央サーバに依存して、問題がある
- 研究されている、とは？提案されている？
- p.5 の段階で 5 分経過した。
- p.6
- A, B, C の機能が必要となるモチベーションについて説明がほしい
- p.7
- 図中の DFS とは？（distributed filesystem?）
- p.9 10 分経過
- PC 上ユニキャスト層とは？どこから PC が出てきたのか不明瞭
- p.10
- Peer ID とは、どれ？
- 暗号アドレッシングとは？
- p.11
- 携帯電話のインフラとは？
- どんな目的だったか言わなくてもよさそう。機能評価でそれが満たされていることを説明しているのは明らかであるため
- p.12
- 表の中に単位がない
- 33 秒かかるのは、実用性があると言えるのか。どのようなユースケースなら実用性があると言えそうか。
- p.13
- シグナリングチャネルとは
- 検閲耐性を得るためには、下位層の通信路それぞれが検閲された際に回避できるという旨を述べたほうがいいと思う（この理解であっているか？）
- p.14