要約

  • 10月27日付の個人Internet-Draft第01版は、TLS 1.3の暗号スイートとは別にSHAKE256またはTurboSHAKE256の鍵スケジュールを交渉する。第00版が対象外としていたDTLSとExported Authenticatorにも規則を広げた。
  • 認証器がTLSライブラリの外にある場合、選ばれたKDFの識別子、または新KDFを使わなかったという情報に加え、TLSかDTLSかを受け取らなければならない。エクスポーターの出力だけでは足りない。

ライブラリ担当が新しい鍵計算を実装し、接続試験を通す。認証器を担当するアプリ側には、エクスポーターの出力だけが届く。この構成では、アプリは受け取った値をどの規則で検証すべきか判断できない。XOF鍵スケジュール草案の第01版は、握手後の本人確認に必要な選択情報をこの境界で渡すよう明記した。

草案のschedule_profile拡張は、鍵導出関数を暗号スイートと別に選ぶ。新しいKDFを交渉しなければ、TLS 1.3の従来どおり、スイートのハッシュを使うHKDFが動く。SHAKE256かTurboSHAKE256を選んだ接続では、そのKDFが鍵導出と通信記録のハッシュを担う。スイート名には元のハッシュが残るが、鍵スケジュールはもうそれに従わない。名前札を見ただけの資産台帳は、動いているエンジンを取り違える。

7月の第00版はDTLS 1.3とExported Authenticatorを明示的に対象外とした。今回の改訂は四つのRFCを更新する案を掲げ、後者の扱いを第14.2節に書き込んだ。RFC 9261のExported Authenticatorは、握手が済んだ後に通信相手が本人確認を行う仕組みだ。従来の認証器ハッシュは暗号スイートのハッシュに結び付く。XOFを選んだ場合、新草案はこれをKDFの64オクテットのTranscriptHashに替え、導出値とFinishedのMACもそのKDFに合わせる。

問題はライブラリの外にある認証器だ。第14.2節は、その実装に選択済みKDFの識別子を渡すよう要求する。新KDFを使わなかったなら、その事実を渡す。さらにTLSかDTLSかも必要だ。DTLSでは内部のスケジュール用ラベルが異なる。TLS-Exporter(label, context, length)だけを提供するAPIでは、これらの選択が伝わらない。ライブラリだけを更新すれば、隣のアプリが互換性のない認証器を作り得ると草案は明記する。

RFC 9258のKDF識別子は、取り込む事前共有鍵にも使われる。改訂案は再開用のチケットにもKDFの結び付きを残す。一方、証明書の署名方式は別に交渉する。鍵スケジュールからSHA-2を外しても、署名や証明書チェーンには残り得る。Datatrackerの状態は個人草案のI-D Exists。外部認証器が新KDFで実際に相互接続できたという公開試験は見当たらない。TLSとDTLSの双方でFinishedを検証する結果が、その空白を埋める。