要約

  • 第 12 版は作業中の Experimental Internet-Draft であり、RFC や実装・展開の証拠ではない。
  • HTTPS で認証された /.well-known/origin-svcb JSON は希望する構成を示すが、DNS 書き込み権限は運用者の登録と zone factory の方針に残る。
  • 一つの ECH 接続成功は、全エンドポイント、全アドレス、DNS 公開、キャッシュ収束、アプリ結果を証明しない。
  • 一般クライアントがこの URI を DNS の代わりに使うと、ECH なしの起動で名前を露出し、個別構成による追跡面を作り得る。

検証には分母が必要である

SVCB と HTTPS レコードは、接続先とサービスパラメータを DNS で配布する。ECH の公開構成は比較的頻繁に変わるため、TLS を管理する源泉と権威 DNS が別なら同期経路が要る。origin-svcb 草案は、源泉が well-known JSON を提示し、zone factory が取得・検証・変換する経路を定める。

ECH の場合、zone factory は公開前に提示されたエンドポイントで ECH が成功するか確認すべきである。DNS にまだ出ていない ECHConfigList を使い、ECH の成否を観測できる専用クライアントが必要になることもある。

ただし「成功」は対象を明記しなければ意味が広すぎる。端点、IPv4/IPv6、ECHConfig の要素、証明書名、ALPN、ポート、時刻が分母である。一点を試して全リストを承認してはならない。

GREASE は単純な全件成功を拒む

ECHConfigList には、GREASE のため意図的に動作しない構成が含まれる場合がある。したがって全要素が接続成功することを要求する検証も、どれか一つが成功すれば十分とする検証も正確ではない。

期待される失敗と本当の設定不良を区別し、どの要素が公開対象として機能すべきかを記録する必要がある。リストの parser 成功は、個々の意味や結果をまとめて保証しない。

複数 CDN ではさらに難しい。zone factory が一社のアドレスだけに到達し、他のアドレスも同じと仮定すれば、公開後に一部クライアントだけが失敗する。テスト範囲は公開範囲に対応しなければならない。

JSON は DNS への命令ではない

HTTPS 取得の成功は、特定 origin が証明書で認証された接続上で文書を返したことを示す。それだけでは、その文書が登録済みか、変換可能か、方針に合うか、zone が更新されたか、クライアントが見たかは分からない。

草案は default で JSON からレコードを合成しないことを求め、合成の有効化には運用者の設定変更を必要とする。公開ファイルの発見を DNS 委任に変えないための統制である。

登録台帳には origin、ポート、owner name、record type、検証方針、責任者、policy epoch を残す。任意の SVCB-compatible owner name には、一般にそれを支配する固有の HTTP origin がないため、完全な URL またはローカル入力との明示的な対応が必要になる。

origin と port が権限の輪郭を作る

源泉は自分自身についてだけ話せる。8443 のサービスを扱うなら、その origin の well-known URL を取得して port-prefixed owner name を検討する。443 のファイルから、同じホストにある別ポートを自動発見する権限は生まれない。

AliasMode や中間事業者も責任を消さない。CDN を使う origin は、JSON が現在の仲介構成を正しく表すようにする責任を持つ。

split-mode ECH では client-facing server と backend が別の名前を持つ。backend が上流のパラメータを認証された手段で取得したという証拠と、backend 自身の JSON を zone factory が HTTPS で認証したという証拠は別である。

parse 後にも拒否する理由がある

JSON は regeninterval と endpoints を持ち、未知の top-level key は無視される。空の endpoints はエラーである。ServiceMode、AliasMode、priority、target、params の表現が可能でも、生成されるレコードは SVCB/HTTPS の規則を満たさなければならない。

未知の SvcParamKey を変換できない、または生成 fragment が検証に失敗するなら DNS を更新してはならない。この拒否は origin に直接見えない可能性がある。HTTP 200 だけを監視すると、正しい拒否を公開成功と誤記する。

取得本文 hash、parse、正規化 endpoint、拒否項目、生成 RRset hash、policy version、最終 decision を保存する。「変更なし」「変更あり・無効」「有効・方針拒否」は別の状態である。

アドレスヒントは証明書検証を省略しない

ipv4hint や ipv6hint が backend の A/AAAA と異なる場合、zone factory は関連アドレスで webPKI 認証が機能するか確認すべきである。ヒントはルーティング候補であり、名前への権限を独立に証明するものではない。

一時的に backend が侵害され JSON を変更された場合、弱い検証鎖では選ばれたヒントがより長い DNS や証明書支配に寄与し得る。これは観測済み攻撃の主張ではなく、同じ入力だけで routing と identity の両方を閉じないための脅威モデルである。

zone factory が CAA も管理するなら、証明書発行時の認可を追加材料にできる。だが CAA 検査も実際の DNS 公開やクライアント接続の代わりではない。

更新頻度と失効時刻は違う

regeninterval は replacement が生成され得る周期であり、厳密な期限ではない。zone factory はそれより短い TTL を選び、期限前に取得と zone 再生成を試みるべきである。

それでも origin 生成、poll、zone commit、権威同期、recursive cache、client cache は別の時計で動く。ECH の retry_configs による version skew 許容もあるため、一つの時刻で「全切替」を宣言できない。

複数 zone factory は同じ JSON から異なる結果を作り得る。一方が未知 parameter を拒否し、もう一方が理解することも、local policy で TTL を調整することもある。文書 hash だけでなく semantic RRset hash と authority probe が必要である。

withdrawal は未定義の統制面である

草案は origin を polling list に追加・削除する方法や、client-facing server が HTTPS RR の全削除を依頼する方法を定義しない。参加をやめた origin の古い JSON が残り、zone factory が polling を続ければ、望まない公開が続く可能性がある。

404 を自動削除命令にするのも危険である。一時障害、経路誤り、設定ミスかもしれない。一方で無期限保持も stale endpoint を残す。withdrawal authority、effective time、replacement、zone serial、cache drain を独立した運用契約にする必要がある。

ECH、address hint、alias は同じ fail state を持つとは限らない。リーダーシップが事前に残存期間と回復手段を決める。

一般クライアントは制御 URI を使わない

well-known resource は公開アクセス可能でも、一般 HTTP client は preferred DNS resolver の HTTPS/SVCB query の代わりに使うべきではない。bootstrap 接続では ECH を使えず、守ろうとした名前を露出する。

origin が fetcher ごとに固有構成を返せば、予想外の tracking vector にもなる。DNS の共有 cache と policy を通る配布と、個別 HTTPS 応答は性質が異なる。

client receipt には resolver path、RRset generation、cache age、selected endpoint、ECHConfig、handshake と application result を含める。JSON fetch は zone-factory control path に限定する。

出典と限界

凍結資料は第 12 版と公式記録、履歴、参照、TLS WG、SVCB/HTTPS、ECH DNS bootstrap、ECH、well-known URI、TLS 1.3、ACME、CAA、IANA registry、key-share prediction から成る。

これらは protocol と registry の本文を確立するだけで、zone factory、DNS operator、CDN、実装、公開、ECH 成功、cache convergence、certificate issuance、privacy leak、tracking、侵害、application result を確立しない。冒頭は validation coverage を考えるための構成例である。

出典