QUIC over DTLSの提案仕様

20180601追記
asnokaze.hatenablog.com


QUIC over DTLS」という提案仕様ekr氏が出され、QUIC WGのメーリングリストで「Proposal: Run QUIC over DTLS」としてDTLS上でQUICのメッセージを通信するように変更する提案がされている。

QUICのスタック

現在のQUICのスタックは図のようになっている。
f:id:ASnoKaze:20180306233002p:plain

QUICが提供する信頼性のあるトランスポート上のStream 0でTLS1.3のハンドシェイクのメッセージ(Crypto Handshake)をやりとり、そこから得れられたシークレットから鍵を生成し通信を暗号化します。

詳細は、tatsuhiro-t先生の記事が詳しいです。
https://qiita.com/tatsuhiro-t/items/2c4e40923c5e359ca235qiita.com

しかし、ekr氏の提案で述べられているように、Crypto HandshakeはStream 0に特殊なルールを適用することになっていたり、0-RTTやACKに関するルールを複雑化していると述べています。また、QUICとTLSスタックを密結合にしているとも書かれています。

提案されている 「QUIC over DTLS」では、QUICのスタックは以下のようになります。
f:id:ASnoKaze:20180306234235p:plain

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