要約

  • RFC 9662 は ECDHE/GCM を優先される共通実装基準に加え、移行用の RSA/CBC を残し、TLS と DTLS に異なるバージョン規則を置く。
  • TLS 1.3 early data の禁止は replay の危険な入口を閉じるが、通常のハンドシェイク後に送ったログの一回配送や保存を保証しない。
  • 実用的な受領証拠は、接続 epoch と証明書検証をイベント ID、送信、collector 受理、永続書込み、index、readback に結び付ける。

試験結果には「0-RTT 拒否、合格」とあった。ところが障害調査で必要になったイベントは検索結果に現れなかった。試験が誤っていたわけではない。証明した範囲が、経営判断で必要な範囲より短かったのである。

RFC 9662 は、TLS と DTLS で運ばれる syslog の暗号相互運用基準を更新する。旧仕様が中心に置いた TLS_RSA_WITH_AES_128_CBC_SHA を移行期の実装必須集合に残し、forward secrecy を持つ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を追加して優先する。これは現実の機器更新速度を認めた設計だ。

同時に TLS 1.3 の early data を明示的に禁じる。syslog 自体が replay protection を提供せず、early data の replay と forward-secrecy 上の性質が通常の通信より弱いからである。しかしこの正しい禁止から「通常経路なら失われない」という結論は導けない。

禁止された経路と証明された経路を分ける

0-RTT の検証は、client が syslog application data を early data として送らず、collector も受け入れないことを確認する。ここで観測すべきものは session resumption、early-data offer、reject、そして接続の確立後に application data が始まった時点である。

通常経路の検証は別だ。テストイベントを作り、source queue、接続 epoch、送信試行、transport result、collector acceptance、durable write、index assignment、retention class、後日の検索まで同じ ID で追う。前者に合格しても、queue overflow、再接続時の脱落、UDP loss、collector reject、誤った tenant、storage failure、indexing fault は残る。

syslog protocol はメッセージ形式を定めるが、暗号 transport の成功から end-to-end exactly-once semantics を生み出さない。危険な一つの入口を閉じることは重要だが、全経路の受領証に読み替えてはならない。

TLS と DTLS は同じ版番号でも同じではない

TLS transport mapping では TLS 1.2 が実装必須のまま残り、TLS 1.3 は対応が推奨され、実装されていれば旧版より優先される。DTLS transport mapping では DTLS 1.0 を使用してはならず、DTLS 1.2 を使用しなければならない。DTLS 1.3 は対応が推奨され、実装時には優先される。

RFC 8996 の旧版非推奨化と RFC 9325 の安全利用指針は、その方向を説明する。ただし監査記録が「1.2」だけなら transport が欠けている。TLS 1.2 と DTLS 1.2、TLS 1.3 と DTLS 1.3 は、loss、ordering、reconnect、acknowledgement の面が異なる。

長時間の TLS 接続では、handshake はイベントよりずっと前かもしれない。DTLS の保護された datagram は application acknowledgement を得たことにならない。したがって transport と connection epoch をイベント証拠に含める必要がある。

実装、設定、offer、選択は別々の事実である

RFC 9662 は ECDHE/GCM と RSA/CBC の双方を実装必須とし、前者を優先する。実装必須は全 interface で有効にせよという意味ではない。設定された suite も、その接続で offer されたとは限らない。offer されても peer と重ならなければ選択されない。

旧 RSA/CBC は、device 更新まで syslog を止めないために管理者が許可できる移行 bridge である。廃止を急げば最も古い機器の telemetry を消すおそれがあり、期限なく残せば例外が恒久化する。device class、firmware、peer、理由、owner、expiry、compensating control、upgrade test、実際の negotiation 回数を一つの例外記録に置くべきだ。

IANA TLS registry は identifier と status を調整する。だが、どの endpoint が何を設定し、どの接続で何が選ばれたかは観測しない。標準、registry、product capability、local policy、running connection は権威の異なる層である。

認証済み channel の先にも障害点がある

RFC 5280 の証明書 path validation は重要だが、期待する trust anchor、reference identity、local authorization の確認も必要だ。暗号的に有効な chain が、意図した collector を意味するとは限らない。

意図した peer を認証できても、それは channel の事実にすぎない。特定イベントが channel に入り、collector に受理され、durable storage に書かれ、正しい index に入り、retention 期間内に読めたかは別の custody chain である。

失敗も区別する。no shared suite、forbidden version、certificate path error、identity mismatch、unauthorized peer、early-data attempt、connection break、queue overflow、datagram loss、collector rejection、storage failure、search mismatch を一つの「secure syslog failure」に畳むと、修復責任を割り当てられない。

検索結果から逆向きに受領証を組み立てる

最初の問いは、許可された調査者が期待したイベントを retention window 内に取得できるか、である。検索結果を durable object と collector acceptance に結び、acceptance を send attempt、connection epoch、source queue に結ぶ。connection を negotiated version、suite、resumption、early-data state、peer certificate、policy revision に結ぶ。

RFC の canonical text、XML、information page、errata、Datatracker history は規範の来歴を確定する。しかし運用の結果は running system だけが記録できる。

Heng Lu の Minimum Initial Specification は共通の最小基準と local decision の責任を両立させる。Reality Layers は規範ラベルと観測結果を分離する。Running-Code Primacy は実際に negotiated、carried、accepted、retained された事実へ権威を戻す。

RFC 9662 は暗号床を正しく修復した。その成果を守るには、0-RTT 拒否、modern handshake、message delivery を三つの主張として検証する必要がある。一つの緑色の試験結果に、残り二つを代弁させてはならない。

出典