要約

  • draft-ietf-tls-tlsflags-18は、内容を持たない最大2,040個の機能表示を一つのTLS拡張に収める。Proposed Standardを意図する現役Internet-Draftで、IESG状態はI-D Existsであり、RFCでも導入実績でもない。
  • セットされた同じビットでも、能力、利用意図、提案、応答、許された一方的通知を表し得る。応答の要否と0-RTTでの意味は各フラグの定義仕様が決める。
  • Daniel Kadeは、メッセージ、役割、方向、仕様版、transcript証拠、再開条件、実際の結果と判断を結ぶ解釈エンベロープを提案する。IETF要件ではなく編集上の統制である。

ある運用チームは、TLS機能の導入率をダッシュボードにした。入力はフラグ番号と真偽値だけだった。数週間後、増加したのは利用された接続ではなく、サーバーが発行したticket上の通知だと判明した。

集計は正確だった。名付け方が誤っていた。通知を「有効」、提案を「対応済み」、対応を「実行済み」と一段ずつ押し上げていた。

第18版は維持であり、完成ではない

Datatrackerによれば、第18版は2026年9月10日公開のTLS Working Group文書で、Proposed Standardを意図する。IESG状態はI-D Exists、WG状態はWaiting for Implementationで、担当ADとtelechat日はない。

履歴と17→18の公式差分を見ると、変更は版、日付、失効日の更新である。動作規則は変わっていない。新しい日付はRFC化、相互接続試験、製品採用を意味しない。

TLS WGが扱う効率問題は明確だ。存在だけが情報である拡張も四オクテットを使う。機能ごとに空の拡張を増やす代わりに、一つのbit stringへまとめれば限界費用を小さくできる。

しかし、共有されるのは符号化の器であって、各機能の状態遷移ではない。

最小長は意味の一意性ではない

第18版本文は1〜255オクテット、位置0〜2039を定義する。各オクテットでは下位ビットから詰め、最後に立つビットを含む最短長にする。全ゼロや末尾ゼロオクテットは無効で、fatal illegal_parameterとなる。

これは同じビット位置を読むための規則である。ところがflag-type featureの存在は、機能のsupportまたは利用intentを示す。能力と意思は別物だ。

実装が機能を知っていても、その接続で提案しないことがある。提案しても、応答を必要としない仕様がある。応答があっても、後で機能が使われないことがある。使われても、アプリケーション方針が結果を許可しないことがある。

したがって、ビット番号だけからenabledを作ることはできない。

メッセージが動詞を決める

一方的なフラグを置けるのはClientHello、CertificateRequest、NewSessionTicketである。ServerHello、EncryptedExtensions、Certificate、HelloRetryRequestに置くフラグには、対応する先行提案が必要だ。不正な一方的応答は接続を終了させる。

ClientHelloならクライアントの提案である。ServerHelloやEncryptedExtensionsなら、個別仕様が求める場合の応答になり得る。NewSessionTicketのサーバー通知にはクライアント側の応答メッセージがない。CertificateRequestとCertificateでは提案側が逆になる。

supported=trueはこれらを同一視する。offered/acceptedという固定モデルも、応答不要のフラグには合わない。WG issue 19が残した結論は、応答の要否を各フラグに委ねることだった。

応答がないことを、一般則で拒否と呼んではならない。

同じビットの応答は利用結果ではない

応答を必要とするフラグでは、同じビットだけが正しい応答となる。返答に内容が要る機能は通常の構造化拡張を使い、この器に載せてはならない。

同じビットが往復したという事実は、定義された信号手順に従ったことを示す。機能が後で実行されたこと、成功したこと、アプリが承認したことまでは示さない。

RFC 8446のpost_handshake_authが境界を説明する。クライアントは後続認証に応じる意思を示す。しかし、サーバーがCertificateRequestを送ったか、証明書が提示されたか、権限が与えられたかは別の証拠である。

一つの空拡張が正しく表せるのは、連鎖の最初の狭い事実だ。

0-RTTでは時点を失ってはならない

再開時の0-RTTデータは、新しいhandshakeが終わる前に送られる。tls_flagsは該当メッセージに入れられるが、すべての将来フラグに共通する早期データ意味は定義しない。個々の仕様が0-RTTとの関係を記述する。

issue 16は、この器がencoding frameworkであり、各機能が早期データ規則を負うと整理した。ticketから引き継げる状態もあれば、新しい確認が必要な状態、次回再開だけに効く通知もある。

保存時にfull/resumed、0-RTTのoffer/accept/reject、ticket、決定時刻を落とすと、後のtrueが先に送られたデータへ遡及する。特に認証や安全制御では、まだ成立していない状態で過去の行為を正当化してしまう。

見えなかったことと、送られなかったこと

草案はServerHelloとHelloRetryRequestの応答が受動観測者に見えると警告し、理由がなければ暗号化メッセージを選ぶよう促す。

経路センサーは平文位置を見られてもEncryptedExtensionsを読めない。endpoint logは復号後のtranscriptを持つが、その権限と保持責任も大きい。TLS終端装置の証拠は自身が参加した区間に限られる。

よって「フラグなし」は観測点なしには成立しない。暗号化で見えない、capture開始が遅い、parserが位置を知らない、といった可能性をpeerの沈黙と混同してはならない。

Registryは地図であって実行履歴ではない

第18版はValue、Flag Name、Message、Recommended、Referenceを持つTLS Flags registryを要求する。0〜15はStandards Action、16〜2039はRFC 8126のSpecification Requiredである。初期候補は値8のresumption_across_names、NewSessionTicket、Recommended Nだ。

調査時点のIANA TLS ExtensionType registryには、器であるtls_flags自体が値62、CH/SH/HRR/EE/CR/CT/NST、Recommended N、第14版参照として載っていた。この行は番号調整の現状を示すが、製品や個別フラグの実装証明ではない。

RFC 8447によれば、Nは欠陥判定ではない。限定用途、特定用途、必要なIETF合意の不在などを含む。designated expertの登録判断もendorsementではない。issue 32はY/N/Dへの整合と、Recommendedが後続文書で変わり得ることを扱った。

TLS 1.3 bisとTLS registry bisも現時点では作業文書だ。Registryは解釈先を示す。実際に送られ、理解され、使われたかは別の記録が要る。

Fatal alertにも原因の限界がある

全ゼロ、末尾ゼロ、提案のない応答でhandshakeを止めたなら、違反メッセージと規則を記録できる。しかしalertだけでは、古いlibrary、古いregistry、serializerの不具合、実験設定、攻撃入力のどれかを決められない。

「機能障害」ではなく、送信role、方向、message、raw値のhash、parser版、違反規則、alertをまず保存する。原因、修正責任、再開判断は後段の欄にする。

フラグ解釈エンベロープ

Daniel Kadeが提案する解釈エンベロープは、transcriptの限定参照、TLS版、full/resumed、0-RTT状態、送信roleとdirection、正確なmessage、container値、raw bit string hash、最小長、bit位置、registry snapshot、定義仕様と版を結ぶ。

さらにproposal、acknowledgement、許可されたunsolicited indicationを区別し、応答要否、先行提案、検証結果を記す。passive visibilityとendpoint visibility、parserとpolicyの版も分離する。

最後に、understood、selected、exercised、failed、superseded、unknownの実結果を保存し、利用できる判断、owner、consumer、保持期限、不確実性、失効、closureを付ける。

これはIETFが求める追加プロトコルではない。秘密鍵を保存する提案でもない。正しいbitが証明していない状態へ昇格するのを防ぐ運用上の記録である。

主張を一段ずつ進める

「NewSessionTicketでbit 8を観測」はwire/transcriptの主張。「仕様Rに基づくcross-name resumption通知」は解釈。「clientが後で試行」は実行。「serverがpolicy Pで受理」は判断。「applicationがidentityを承認」はさらに後の結果だ。

bit containerの価値は重複するbytesを減らすことにある。証拠の動詞まで減らしてはならない。TLSフラグはmessageに存在した事実を示せるが、単独では機能状態の記録にならない。

情報源