要約

  • 提案された署名鍵は、ECH の再試行設定を認証する役割を担う。
  • 稼働率だけでは、プライバシーを変える指示の管理責任は見えない。

障害対応では、まず通信を戻すことに目が向く。しかし、どの条件で戻したかも重要だ。TLS の内部 ClientHello を暗号化する ECH について、署名付き更新の草案は、初期設定で認めた鍵を使って再試行設定を認証する仕組みを提案している。認証済みの指示によって、ECH を使わずに再接続することもできる。

現在の ECH 仕様は、公開名に有効な証明書を使って再試行情報を認証する。提案は、その役割を別の署名鍵に持たせるものだ。DNS による初期設定の配布や接続先の認証まで一括で保証するわけではない。

運用上の論点は、鍵の保管責任と変更権限を誰に持たせるかだ。通信成功の記録だけでは、その指示を誰が認めたのかは分からない。復旧担当とプライバシー管理担当を同じ組織が兼ねる場合でも、説明すべき責任は分けられる。

2026年7月6日付の個人草案であり、承認済み標準や実装普及の発表ではない。導入の判断に先立ち、再接続の鍵を誰が預かるのかを明確にする価値はある。