要約

  • ECHは本当のSNIなどをClientHelloInnerに入れて暗号化し、公開可能なClientHelloOuterに包んで共有フロントへ送る。
  • DNSが最新設定を届け、フロントが鍵を維持し、バックエンドが受理を確認し、失敗が黙って平文へ落ちないことまでが一つの契約である。
  • DNS問い合わせ、宛先IP、通信相関は別の観測面として残る。ゾーンにechがあることは、受理された接続の証明ではない。

ひとつの接続に二つの名乗り

RFC 6066のserver_nameは、同じ設備を共有する複数サービスから一つを選ぶための仕組みだった。RFC 8446ではClientHelloがTLS 1.3の最初のメッセージであるため、その名前は後続の暗号化より前に見えていた。

2026年3月にStandards Trackとして公開されたRFC 9849は、名乗りを内外に分ける。内部には真のSNIやALPNを置き、ECHConfigの公開鍵を使うHPKEで暗号化する。外部には公開名とencrypted_client_hello拡張を置き、その中に暗号化済みの内部を収める。

フロントが受理すれば内部を処理または転送する。開けなければ外部で処理し、最新の再試行設定を返せる。クライアントは受理を判定する。ECHを提示して拒否された接続はアプリケーションデータには使わず、更新された設定でやり直す。

共有フロントは単なる通過点ではない

共有モードではフロントとTLS終端が同じである。分離モードではフロントが内部Helloを開き、別のバックエンドへ渡してTLSを終端させる。フロントは経路選択に必要な名前を知る一方、アプリケーション本文を終端する必要はない。

DNS運用者は設定を公開し、クライアントは利用を選び、フロントは秘密鍵とキャッシュ中の旧設定を維持し、バックエンドは内部トランスクリプトに受理を結び付ける。どれか一つの「正常」表示では、全体の成立を証明できない。

鍵の更新には相反する要請がある。速い更新は漏えい時の影響時間を縮めるが、古いTTLを持つ利用者の再試行を増やす。旧鍵を多く残せば試行復号の負荷が増える。RFCは手順を定めても、全サービス共通の更新間隔は定めない。

TLSより先にDNSが指示を渡す

RFC 9848は、RFC 9460のSVCB/HTTPSレコードにechパラメーターを定義する。クライアントは接続前に、候補エンドポイントと設定を受け取る。

ECHありとなしの候補を同じRRSetに混ぜると、保護された候補だけを遮断して非ECHへ誘導できるため、RFC 9848は推奨しない。SVCB解決そのものを妨げれば、クライアントは保護方針が存在したことさえ知らない。

暗号化DNSはアクセス網の観測者を抑えるが、再帰リゾルバーから問い合わせ名を隠すものではない。フロントのIPも残る。ECHが守るのは明示されたハンドシェイク情報であり、接続全体の不可視性ではない。

匿名集合は外見まで共有して初めて成立する

複数の名前が設定と公開挙動を共有する必要がある。名前ごとに別の識別子を割り当てれば、集合は一つに縮み得る。暗号スイート、拡張順序、レコード境界、再試行cookieの違いも外形を分ける。

内部の暗号化に成功しても、外部が名札になっていれば目的は弱まる。評価では同じ集合の複数名を並べて比較しなければならない。

GREASEが故障の意味を限定する

GREASE ECHは実際の設定がなくても似た拡張を送り、中間装置の非互換を発見し、本物だけが目立つことを避ける。そのため一度の復号失敗だけでは設定不良と言えない。再試行設定の不一致、ノード間ループ、ech_requiredアラートの方が具体的な兆候となる。

固定資料からは分からないこと

RFCは形式、役割、脅威モデルを示すが、特定ブラウザー、リゾルバー、ネットワークの有効化状況や、事業者の実効集合サイズは示さない。ここは測定なしに埋めてはならない。

出典