有効なECH鍵ファイルでも境界を誤り得る

Summary

RFC 9934に従う検査は、PEMファイル内の秘密鍵が少なくとも一つのECHConfigに対応することを確かめられる。それでも、その組み合わせが対象のDNS所有者、配信サーバー群、再試行集合、匿名性集合、運用時期について承認済みであるとは限らない。
必要なのは鍵の複製ではなく、秘密鍵や保護対象名の一覧を明かさずに、設定ダイジェスト、DNS RRSet、エンドポイント群、通常時と再試行時の役割、重複期間、撤回条件、承認者を結ぶ「方針・配備レシート」である。

緑色の判定が答えている問い

ファイル検査の仕事は明快に見える。PEMの区切りが正しく、秘密鍵はPKCS #8として解釈でき、ECHConfigListも復号できる。さらに、リストの中に秘密鍵と対応する公開設定が少なくとも一つある。破損も不一致もなければ、検査画面は成功を示す。

この成功には実務上の価値がある。ECHの鍵素材を鍵管理基盤からTLSサーバーへ渡す方式が実装ごとに異なれば、ローテーションや製品間の移行は独自形式に拘束される。RFC 9934は、公開リストと必要に応じた秘密鍵を一つの移植可能な容器に収める。秘密鍵はゼロ個または一個とし、含まれる場合はECHConfigList内の設定と一致しなければならない。公開部分には専用のECHCONFIGラベルがあり、秘密部分をDNSに載せてはならないことも明確だ。

ただし、検査が証明する関係は容器の内側で完結する。「この秘密要素は、この公開要素の一つと対応する」という命題である。ファイルを作った主体が対象サービスの境界を決める権限を持つこと、どのDNSゾーンがリストを公開すること、どのフロントエンドに鍵を配ること、どの名前を一つの集合に入れること、どの設定をretry_configsとして返すことまで認められたとは証明しない。

暗号学的な一致は、範囲以上に強い印象を与えやすい。狭い命題への証拠としては確かに強い。しかし、狭い命題の強い証拠が、周囲にあるすべての組織判断の証拠へ広がるわけではない。封をした荷物の受領証は、中身が正しい場所へ運ばれた権限まで示さない。鍵の対応も、それを運用すべきプライバシー境界を決定しない。

運用上の問いは、「このファイルは有効か」だけでは足りない。「どの承認済み配備状態に対して有効なのか」まで必要になる。

一つのリストに複数の判断が入る

RFC 9934は、ECHConfigListに複数のECHConfigを優先順で入れられるようにしている。設定ごとに拡張やpublic_nameが異なる場合もある。TLSサーバーは複数のファイル名を設定でき、その一部だけをECH拒否時のretry_configsに選ぶこともできる。

柔軟性には理由がある。複数設定は新しい方式への移行を支え、優先順は採用の方向を表せる。通常運用、事前配備、緊急復旧を別ファイルに分けることもできる。再試行設定は、DNSで得た設定をまだ受理できないサーバーに当たったクライアントを回復させる。

同時に、各機能は単純な鍵照合では見えない判断を増やす。優先順を誰が承認したのか。新設定は単なる準備段階か、すでに第一候補か。public_nameの変更により、外側の接続を扱う運用主体が増えていないか。サーバーがファイルを読み込めるからといって、同じファイルを再試行で広告すべきとは限らない。反対に、通常の新規接続では使わない旧設定を、キャッシュ済みクライアントのために限定期間だけ受理する場合もある。

「一致する設定が一つ以上ある」という検査は、その役割の差を区別しない。ファイル内の順序が運用意思と一致しているか、複数ファイルの選択が期待した再試行集合を作るかは、外部の方針と稼働状態を見なければ分からない。

ECHはファイルではなく経路全体で働く

RFC 9849はECHプロトコルを、RFC 9848はDNSを用いた発見を記述する。実際の接続では、クライアントがHTTPSまたはSVCB情報を参照し、外側と内側のClientHelloを組み立て、到着したサーバーが適切な鍵を選び、必要なら再試行設定を返す。どれか一段だけが正しくても、経路全体の結果は保証されない。

たとえば、権威DNSが新しいリストを公開したのに、ロードバランサー配下の一地域だけが旧鍵のままなら、DNSの内容も各ファイルもそれぞれ正しく見える。クライアントが新しいノードに着けば成功し、古いノードに着けば拒否や再試行になる。障害は確率的に現れ、単一ホストの監視では取り逃がされる。

逆の時間差もある。サーバー群が先に新鍵へ移ったが、TTLや中間キャッシュのため旧リストを見るクライアントが残る。旧鍵を早く消せば接続が不安定になり、長く残せば保管範囲と漏えい面積が増える。ファイルの妥当性は、この時間上の取引を解決してくれない。

複数クラウドや外部CDNを使う構成では、TargetNameやエイリアスの変更が別の運用主体へ接続を移す。新しい宛先が同じ鍵を持つべきか、別のプライバシー集合に入るべきかは契約とサービス設計の問題である。形式を渡せることと、渡す権限があることは分けて記録しなければならない。

DNS公開は独立した権限である

ECHConfigListは、HTTPSまたはSVCBレコードのechサービスパラメーターを通じてクライアントに発見される。RFC 9460がサービスバインディングの枠組みを定め、IANAのレジストリが割り当て状況を示す。DNSへ載せるのは公開リストであり、秘密鍵ではない。RFC 9934のファイルとDNSの公開内容は対応すべきだが、対応していることは公開権限の証明にはならない。

DNSゾーンの所有者、TLS基盤の管理者、サービス名の責任者が同一とは限らない。DNS担当者が受け取ったダイジェストを公開できても、どの名前が共同利用するかを決める権限は別の部署にあるかもしれない。TLS担当者は鍵を配布できても、外部プロバイダーを新たなTargetNameに加える権限を持たないかもしれない。

さらにpublic_nameは飾りではない。ECHが受理されない場合も含め、外側から見える接続文脈に関係する。RFC 9525のサービス識別とRFC 8446のTLS基盤を合わせて考えると、あるサーバーが鍵で復号できることと、そのサーバーが対象サービスを代表してよいことは別々の主張になる。

配備レシートには、承認されたRRSetの正規化ダイジェスト、ゾーンまたは委任文脈、想定TargetNameとアドレス群、優先順位、TTL前提、公開期間を含めるべきだ。DNSSECや証明書検証、変更管理の代わりではない。それらの独立した判断が同じ配備を指しているか確認する接点である。

サーバー群の欠落はプライバシー結果を変える

DNSで得た設定を接続先サーバーが受理できなければ、問題は稼働率だけにとどまらない。再試行、別経路、実装ごとの失敗処理によって、観測可能な挙動が変わる。通常は大きな集合に紛れていた接続が、一部ノードの反応だけで区別しやすくなることもある。

したがって「サーバーにファイルを配った」は集合に関する命題である。主系統だけでなく、IPv6の宛先、災害復旧サイト、低頻度の予備クラウド、臨時増設、重みゼロから復帰するプールまで含め、クライアントが実際に到達し得る範囲を扱う必要がある。ローリング更新中は、すべてのファイルが正しくても新旧の組み合わせが不整合になり得る。

静的なホスト一覧はすぐ陳腐化する。より実用的なのは、ロードバランサーの対象、サービスアカウント、リージョン、構成ダイジェスト、配備世代などで「エンドポイント群」を定義することだ。レシートは、どの群がどの設定をいつから受理し、いつまで旧設定を維持し、公開経路が群外へ流さないことをどう確かめたかを示す。

証明のために利用者ごとの通信履歴を集める必要はない。群ごとの合成プローブで公開設定のダイジェスト、受理結果、再試行内容、配備世代を確認できる。観測対象は利用者ではなく、運用者が責任を負う基盤状態である。

匿名性集合はPEMに格納できない

ECHは内側のClientHelloにある情報を保護するが、宛先IP、時刻、トラフィック特性など、経路上から見えるものをすべて消すわけではない。複数の名前が同じ外側名、入口、設定を共有すれば区別しにくい集合を作れる。逆に、細かく分割された入口や特有の失敗挙動は集合を縮める。

どの名前を同じ集合に入れてよいかは、ファイル形式には書かれていない。テナント間で解読基盤を共有することが契約上または規制上許されるか、事故時の影響を共同で引き受けられるかも分からない。大きな集合は外部観測に対して有利なことがある一方、鍵の管理権限と障害半径を広げる。小さな集合は内部権限を限定しやすい一方、外から識別しやすくなる。

これは単一の最適値を持つ技術パラメーターではない。サービス所有者、プライバシー担当者、基盤運用者が説明可能な境界を選ぶ必要がある。設定を共有した事実だけで、共有の正当性を推定してはならない。

ただし、監査のために保護対象名の完全な一覧を中央保存すれば、新たな危険を生む。レシートには、集合方針の識別子、版、規模帯、加入規則、テナント隔離区分、禁止される組み合わせ、承認された増減を記録すればよい。適切な権限を持つ監査者だけが元の名簿と照合し、通常の検証者は境界が変わったかどうかを確認する。

再試行設定は通常設定の写しではない

ECHを拒否したサーバーはretry_configsを返せる。RFC 9934は、サーバーが複数の設定ファイルを持つ場合でも、その一部だけを再試行に使えることを明示している。これは、通常受理する集合と再試行で広告する集合が別の運用役割を持つことを意味する。

新鍵は少数ノードに事前配備されていても、まだ全利用者へ案内すべきでない。旧鍵はDNSの第一候補から外れていても、キャッシュ利用者のため受理を続ける場合がある。緊急用ファイルは特定地域でだけ使えるかもしれない。ディレクトリ内の有効ファイルを自動的にすべて再試行へ並べる設計は、形式検査を公開承認にすり替える。

誤った再試行設定は障害を広げる。最初のDNS状態に限られていた不一致が、サーバーから返される別設定によってより多くの接続へ伝播する可能性がある。再試行後も拒否される回数を配備世代とサーバー群ごとに集計すれば、状態分裂の早期指標になる。クライアント識別子や内側名は記録しなくてよい。

レシートでは、通常受理、再試行広告、移行重複、ロールバック待機、退役済みを異なる役割として扱うべきだ。ファイルがまだ保存されているというだけで、前段階の権限を次段階へ持ち越してはならない。

同じ鍵でも時期が違えば別の判断になる

ローテーションは、生成、内部照合、事前配備、DNS公開、全面受理、重複運用、広告停止、キャッシュ対応、破棄という段階を進む。同じECHConfigと同じファイルが複数段階に存在しても、許可される用途は変化する。

キャッシュは組織間の時間差を長引かせる。権威DNSを変更したからといって旧設定を参照するクライアントが直ちに消えるわけではない。旧鍵を保持しているからといって旧広告を無期限に残す理由にもならない。TTL、実測されたキャッシュ期間、対応するクライアント群、鍵漏えい時の優先順位を同じ時系列に置く必要がある。

設定識別子の早すぎる再利用にも注意が要る。バックアップ復元や環境間コピーにより、以前は正しかったファイルが別の時代に再出現することがある。ファイル更新時刻だけでは出自を証明できない。内容ダイジェスト、方針版、生成環境、承認期間を組み合わせて配備上の同一性を定めるべきだ。

撤去も単純な削除ではない。秘密管理システム、ビルドキャッシュ、待機系、運用端末から鍵が消えた証拠と、DNSやエイリアス経路から公開リストが消えた証拠は別物である。鍵破棄と公開停止を別々に確認し、ライフサイクル記録で結ぶ必要がある。

移植性が高いほど所持と権限を分ける

RFC 7468が普及させたテキスト形式の封入は、多様な安全オブジェクトを既存ツールで扱いやすくした。ECHもこの慣習に乗ることで、鍵管理や配備基盤との接続が容易になる。だが、コピーしやすい形式では「持っているから使ってよい」という推定が一層危険になる。

小さな運用では、DNS、TLS、サービス責任が同じ担当者に集まり、口頭の調整でも機能するかもしれない。規模が拡大すると、中央の鍵管理チーム、別会社のCDN、複数のDNS管理者、製品ごとのテナント責任者が関わる。受取人は内部整合性を検証できても、送り手がどの範囲を承認したかをファイルからは読めない。

ここで必要なのは、プロトコルを肥大化させることではなく、制度上の事実を別の検証可能な層に置くことだ。Heng Luの「Policy Mirror」は、表示された状態が実際の決定を映す必要を示唆する。「Minimum Initial Specification」という考え方は、最初から巨大な中央管理を作らず、責任を結ぶ最小限の共通項から始められることを教える。

現実を記述する媒体は、例外や未完了状態も隠さない。配備レシートは理想的な手順だけでなく、部分展開、緊急ロールバック、検証できなかった範囲を記録すべきである。「ファイルは有効だがサーバー範囲は未確認」という黄色の状態は、根拠なく全体を緑にするより有用だ。

最小限の方針・配備レシート

レシートの第一部は暗号オブジェクトを識別する。ECHConfigListの正規化ダイジェスト、検査結果、設定識別子、暗号スイートを含める。秘密鍵は隔離環境で照合に使うだけで、レシートへ出さない。

第二部は公開意図を示す。対象RRSetのダイジェスト、ゾーンまたは委任関係、public_name、SVCB/HTTPS優先順位、公開開始と終了の窓である。第三部はエンドポイント群を定める。ロードバランサー、リージョン、プロバイダー、配備世代、構成ダイジェスト、合成監視範囲を使い、短命な個別インスタンス一覧に依存しない。

第四部は役割を分ける。通常受理、再試行広告、重複のみ、ロールバック用、退役済みを明示する。第五部はプライバシー境界を表す。集合方針の版、規模帯、テナント区分、増減の承認を、完全な名前一覧なしで記録する。第六部は責任と期限を残す。提案者、DNS承認者、鍵管理者、サービス所有者、署名時刻、撤回条件、根拠への参照である。

レシートは署名でき、同じ入力から再検証でき、後から撤回状態を確認できる必要がある。外部の制限付き証拠を参照してもよいが、秘密鍵、全名称一覧、利用者IP、握手記録を内包してはならない。RFC 9180のHPKE、RFC 9849のECH、RFC 9460の発見仕様を再定義するのではなく、それらのオブジェクトがどの現実の判断に使われたかを結ぶ。

自動化は保証の境界を表示する

配備パイプラインは最初にRFC 9934の検査を実行すべきである。形式が壊れ、秘密鍵が一致せず、リストが解釈できないなら停止する。その後に、DNS、サーバー群、役割、匿名性集合、時間窓の証拠を組み合わせる。

DNSダイジェストが未承認なら「ファイル有効・公開未承認」、エンドポイント群が一部しか揃っていないなら「ファイル有効・範囲不完全」、集合変更が未審査なら「鍵一致・境界保留」と表示する。標準の価値を下げるのではなく、標準が実際に保証する範囲を正確に守る表示である。

すべてを人手に戻す必要はない。サービス所有者が共有規則を事前承認し、DNS基盤が変更証拠を出し、オーケストレーターが群のダイジェストを出せば、通常の配備は自動でレシートを組み立てられる。境界を越える変更や証拠の欠落だけを人へ上げればよい。

ロールバックも古いレシートの再利用ではなく、新しい状態遷移として記録する。DNSキャッシュや到達可能なサーバー群は前回から変わっている可能性があるからだ。各遷移は、誰が、何を根拠に、どの境界を、いつまで承認したかを答えられなければならない。

監査を新たな観測装置にしない

ECHが減らそうとしているのは、通信経路から見える名称情報である。監査の名目で内側名、利用者要求、詳細ログを一か所に集約すれば、外部観測者より豊かな関係図を内部に作ってしまう。統制設計は初めからデータ最小化を条件にする必要がある。

サーバー整合性は公開設定のダイジェストと合成試験で示せる。DNS状態は正規化RRSetのダイジェストでよい。集合は規模帯やコミットメントで表せる。再試行失敗は時間窓と粗い群単位で集計できる。個別調査が必要なときだけ、制限環境で詳細証拠を一時的に突き合わせ、保持期限を設ける。

アクセス権も分けられる。セキュリティ担当は鍵破棄を、DNS担当は公開履歴を、プライバシー担当は集合規則を検証する。通常の配備システムは各証明が満たされたかだけを見る。誰がどの事実に責任を負うかは明確にしつつ、一人の閲覧者にすべての秘密を集中させない。

形式標準と運用正当性を混同しない

RFC 9934の仕事は相互運用できるファイル形式を定めることであり、各組織のテナント境界や承認経路を決めることではない。不足しているのはRFCの文章量ではなく、導入側が形式検査を全体承認と読み替えるときの接続層である。

将来、署名付き配備マニフェストやECH運用慣行が標準化されれば、レシートの項目を合わせればよい。それまでは組織固有の形式でも、内容が検証可能で、プロトコル保証と組織判断を明確に区別し、不確実性を残せるなら役割を果たす。

正当性は役割の線引きから生まれる。IETFは相互運用するオブジェクトを定義し、DNS所有者は公開を決め、基盤運用者は到達可能なサーバー群を決め、サービス所有者は共有集合を決める。ファイルを所持する一者へ、他の権限まで暗黙に移してはならない。

最終的に必要なのは二つの別々の合格である。第一は暗号学的なファイル妥当性、つまり秘密鍵が少なくとも一つの公開設定と対応すること。第二は方針上の配備妥当性、つまり正しい公開リストが、正しいDNSから、正しい期間に、正しいサーバー群とプライバシー集合へ適用されることだ。前者がECHを持ち運べるようにし、後者が境界を説明し、監査し、撤回できるようにする。

有効なECH鍵ファイルだけでは正しいプライバシー境界を証明できない

なぜ重要か