MozillaのM. Thomson氏より「More Apparent Randomization for QUIC」というinternet draftが出ています。
## QUICのここまで
QUICはIETFで標準化が進められています。当初は2018年3月が一つのマイルストーンになっていましたが、スコープとマイルストーンの議論をへて、8ヶ月後ろ倒しの2018年11月がIESGへの提出目標となっています(URL)。
後ろ倒しになりましたが、中間ミーティングや実装を持ち寄っての相互接続テストを積極的に行っていくことで議論はより加速する見込みになっています。
また、あわせてスコープの議論も行われ、QUIC V1ではアプリケーションプロトコルとしてHTTPのみをターゲットとすることになっています。V1を策定している最中ですが、将来的にV2が出来た時にいかにそれをデプロイし易いようにするかという議論が盛り上がっています。
Google QUICでは、バージョンアップに伴い既に問題が起きている事が下記の論文で報告されています。
asnokaze.hatenablog.com
TLS1.3でも、この問題に苦しめられ何度も試行錯誤をやりなおしている。
TLS1.3と疎通性の問題
IETF100でも報告されているとおり(URL)、TLS1.2の接続失敗が2.2%だったのに対して、TLS1.3では3.9%でした。
TLS1.3のようにプロトコルのバージョンをあげた時に、FWといった中間装置が不具合を起こし通信をブロックしていたのです。Googleでは、Canonのプリンタなど幾つかを実際に買い動作確認を行ってたりします(URL)
このように、プロトコルのバージョンを上げると中間装置が誤作動を起こしてデプロイが困難になるということがわかってきています。
TLSでは、未知の拡張で不具合が起きないことを確かめるように、以下のようなとりくみも行われています。
jovi0608.hatenablog.com
QUICでの工夫
QUICでは多くの部分を暗号化するとともに、TLSハンドシェイク相当部分を隠蔽する仕組みが有ります。
通常平文であるTLSハンドシェイクのメッセージですが、connection idとV1固有のsaltから導出されるシークレットで暗号化します。これは、メッセージの機密性を得るためのものではなく、将来プロトコルのバージョンを上げた時に、V2固有のsaltを使うようにすることで、V2に対応していないノードはメッセージを見ることが出来ないようするためです。
quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639
handshake_secret = HKDF-Extract(quic_version_1_salt,
client_connection_id)
client_handshake_secret =
HKDF-Expand-Label(handshake_secret,
"QUIC client handshake secret",
"", Hash.length)
server_handshake_secret =
HKDF-Expand-Label(handshake_secret,
"QUIC server handshake secret",
"", Hash.length)このように、最新のバージョン固有のパラメータを使って隠蔽することで、対応してないなら見ることが出来ないようにすることで、将来のバージョンでの中間装置からの影響を緩和しようとしています。
( quic_version_1_salt は、この仕組が導入された draft06のコミットハッシュです (URL) 。これを使うことでdraft-06以降にうまれた値ということが分かります。 )
さらに、以前書いたVariantsもパケットのフォーマットを将来的に固定することで影響を緩和しようとするものです。
asnokaze.hatenablog.com
More Apparent Randomization for QUIC
話が長くなりましたが、QUICにまだ隠蔽されていないPacket Types・Packet Numbers・KEY_PHASEというフィールドについても隠蔽できないかについて検討しているのが、「More Apparent Randomization for QUIC」です。
このInternet Draftでは、小さなフィールドをシークレットで暗合するのは適切でないとし、幾つかの隠蔽案を検討しています。
- 剰余方式：ある値で割った余りを使用する値とする
- XOR：ある値とXORとった値を使用する値とする
- FFX：FFXというアルゴリズムがあるらしい ( https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/proposed-modes/ffx/ffx-spec.pdf )
それぞれの方式でフィールド毎にメリット・デメリットがあるが、このInternet Draftでは考察までにとどめている。
これらの方式はinvariantsの領域にも使用できるが、将来的にこの仕組を使い続ける必要が出来てしまうため、バージョン固有の領域などに使うことで将来的にも改善していくことができる。
