要約

  • 暗号化された ClientHelloInner、外側の包み、そしてクライアント向けサーバーの public_name は別の層にある。public_name は秘匿されたバックエンド名ではない。
  • DNS の設定、ECH の受理、TLS の認証、アプリケーションの成功は別々のレシートであり、一つの成功を別の層へ拡張できない。

RFC 9849 では、クライアントは私的な値を ClientHelloInner に入れ、無害な値と ECH 拡張を ClientHelloOuter に入れる。内側は ECH 公開鍵で暗号化され、外側と内側は追加認証データで結び付けられる。この結合は、同じ内側を保ったまま外側だけを勝手に変える攻撃を抑える。しかし DNS の記録、公開アドレス、前面の事業者、バックエンド、アプリケーション主体が同一であることは示さない。

public_name の役割はもっと狭い。これは クライアント向けサーバー の DNS 名で、ECH 設定を更新し、古い設定からの回復を助けると信頼される名前である。通常は外側 SNI に置かれる。公開の経路・回復用の面であり、隠れたオリジン名でも、匿名集合全体の所有証明でもない。

共有モードでは前面と TLS 終端が同じ主体になり得る。分離モードでは前面が TLS を終端するバックエンドへ転送し、前面は接続の平文を読まない。後者について RFC は、両者の間に認証済みチャネルがあり、攻撃者が二つの区間を相関できないことを仮定する。相関を防ぐ具体的方法は範囲外である。ECH を観測しただけでは、その運用上の前提は監査できない。

受理も限定されたハンドシェイク状態である。サーバーは ECH を受理して inner を使うか、拒否して outer を使う。拒否された接続は ECH クライアントのアプリケーションデータには使えず、新しい設定による再試行につながり得る。受理は inner が選ばれたことを示すだけで、クライアントの信頼ストアが証明書を受け入れたこと、期待する名前が一致したこと、アプリが権限を与えたこと、要求が完了したことは示さない。

RFC 8446 もこの分離を保つ。TLS はパラメータを交渉し、必要により相手を認証して鍵を確立するが、アプリケーションの意味は決めない。信頼アンカーと詳細な検証は独立の問題である。RFC 9460 の SVCB/HTTPS も、公開鍵や代替エンドポイントをクライアントへ知らせる指示であり、代替先は能力も運用者も異なり得る。DNS の一行は、実際に選ばれた終端やサービス結果の証明ではない。

調査では、ECHConfig の出所と TTL、リゾルバとキャッシュ、受理/拒否、期待身元と検証結果、前面・バックエンド間チャネル、選択先、アプリ結果を別々に残すべきだ。一つの暗号化パケットは一列を明らかにしても、他の列を埋めない。

情報源