2021/12/21 追記
この記事は古いです。2018年、QUICの標準化において設計段階で行われた議論になります。
「QUIC over DTLS」という提案仕様ekr氏が出され、QUIC WGのメーリングリストで「Proposal: Run QUIC over DTLS」としてDTLS上でQUICのメッセージを通信するように変更する提案がされている。
QUICのスタック
現在のQUICのスタックは図のようになっている。
QUICが提供する信頼性のあるトランスポート上のStream 0でTLS1.3のハンドシェイクのメッセージ(Crypto Handshake)をやりとり、そこから得れられたシークレットから鍵を生成し通信を暗号化します。
詳細は、tatsuhiro-t先生の記事が詳しいです。
qiita.com
しかし、ekr氏の提案で述べられているように、Crypto HandshakeはStream 0に特殊なルールを適用することになっていたり、0-RTTやACKに関するルールを複雑化していると述べています。また、QUICとTLSスタックを密結合にしているとも書かれています。
提案されている 「QUIC over DTLS」では、QUICのスタックは以下のようになります。
DTLSのハンドシェイクを行った後、その上でQUICのメッセージをやり取りするようになります。
それに伴い、この提案仕様でQUIC部分も変更される部分が出てきます。
- QUICのVersion Negotiationの変更 (DTLS1.3のsupported_versionsに加え quic_versionsのネゴシエーション)
- Transport ParametersはTLS拡張へ
- DTLSの提供するACKと、QUICの提供するACKが分離する
もちろん、QUICとDTLSスタックとやり取りする必要もあるし、そのままDTLSを利用できない部分もあります。
DTLSの変更
QUICの仕様も既に長い間議論されてきており、沢山の事が考慮され現在の形になっています。
そのような様々な考慮事項を満たすために、DTLSはそのまま使用できません。提案仕様の「3. Required Changes to DTLS」にかかれているとおり、幾つか変更する必要があります。
- DTLS1.3 Connection ID: 別途議論されているDTLSにコネクションIDを導入する拡張の仕様 (「DTLSにコネクションIDを導入する提案仕様」)
- ハンドシェイクメッセージの難読化
- ネゴシエーションパケットの難読化
- パケット番号の暗号化
- Stateless Reset: サーバがリブートなどして、コネクションの状態情報を失った時に接続をリセット する手段を提供する
各種メッセージの難読化については、以前書いたとおり
asnokaze.hatenablog.com
実装
ekr氏は既に「QUIC over DTLS」を実装しています。
github.com
議論
QUIC WGのメーリングリストで、議論は盛り上がっています。
やはり大きな変更となるため、興味を持つものの好意的でない意見の方が多い印象です。今まで沢山の議論を重ね、GQUICからの知見も得て、QUICは今の仕様になっています。今のデザインのまま、まだまだ改善できる余地はあるのではないかという感じでしょうか。
今月ある IETF101のアジェンダにも既に含まれています。議論となることでしょう。
github.com
