要約

  • RFC 3546は、拡張同士の相互作用が全体の安全性を損なう可能性を理由に、新しいTLS拡張とアラート番号へIETF Standards Actionを求めた。
  • RFC 8447は2018年、ExtensionTypeの先頭オクテットが0〜254の値をSpecification Requiredに改め、「Recommended」を登録とは別の欄にした。

歴史上の転換は、TLSの名前空間が広がったことだけではない。共有レジストリへ新しい意味を持ち込む手続きが変わり、登録と推奨を区別する設計が明示された。

2003年6月のRFC 3546は、TLSのHelloメッセージに拡張を載せる共通形式と、六つの初期タイプを定めた。タイプ番号は拡張の種類を識別し、拡張データが固有の意味を運ぶ。同文書はエラーアラート番号の追加も扱う。新しい拡張やアラートの割り当てにはIETF Standards Actionを要求した。新機能が既存機能と組み合わさることで、全体の安全性を低下させる可能性があるからだ。すべての提案を危険と判断したのではない。機能を個別に見るだけでは相互作用を捉えにくいという設計上の懸念だった。

プロトコルにも対応する注意点があった。TLSハンドシェイクの認証前には、能動的な中間者がHelloメッセージの拡張を改変できる。Finishedメッセージは通常、ハンドシェイク内容を認証に結び付ける。それでも、別の機能がFinishedの意味や結果を変えないかを設計者は考慮する必要があった。これは脅威モデルと設計義務の説明であり、実際の攻撃事例ではない。登録規則は共有空間に何が入るかを扱い、プロトコルの保護は個々の接続で何が認証されるかを扱う。

2006年のRFC 4366はRFC 3546を廃止し、ExtensionTypeの割り当てをIETF Consensusで定めた。新しい値はIESG承認済みRFCによる、と説明している。用語は変わったが、IETFの手続きが入口を管理する点は続いた。2018年のRFC 8447は、TLS拡張に対するIETF Reviewは厳しすぎるという作業部会の判断を記録し、先頭オクテットが0〜254の値をSpecification Requiredに変更、255をPrivate Useに予約した。

Specification Requiredは審査なしを意味しない。RFC 8126は指定専門家による確認と、相互運用に十分な恒久的・公開可能な文書を求める。RFC 8447はTLSレジストリのメーリングリストで三週間のレビュー期間を設け、専門家の助言を求める。専門家は公開された仕様があることを確認し、より詳しい審査もできるが、承認は拡張の推奨や保証ではない。審査の入口は、広範な標準手続きから文書化された提案への確認へと移った。

同RFCは「Recommended」欄も追加した。これは実装が一般にサポートすべき項目を示す別のシグナルだ。Nは欠陥を意味しない。IETFコンセンサスがない、適用範囲が限られる、特定用途向けといった事情を示し得る。反対に、登録されたという事実だけでは、実装の存在、通信相手との交渉、運用者による有効化、安全性の評価は分からない。

したがって、レジストリは共通識別子を調整するが、仕様、推奨、実装、稼働状況を一つの印にまとめることはできない。登録手続きが緩和されても、RFC 3546の相互作用への警戒は消えなかった。その確認は公開文書、専門家、標準化、各実装の判断へ分散した。歴史を正確に読むには、それぞれの証拠を分けて扱う必要がある。

出典