要約

  • RFC 9540 は SVCB／HTTPS レコードに空値の ohttp パラメータを設け、同一ホスト上の /.well-known/ohttp-gateway と鍵設定の取得方法を定める。
  • この仕組みはリレーを発見も認証もしない。DNS 広告、証明書、利用可能な鍵、通信完了は、それぞれ別の事実である。
  • 個別の鍵設定、リダイレクト、dohpath は利用者を再識別し得るため、一貫性には独立した観測証拠が要る。

障害率はゼロだった。試験端末はいずれも OHTTP 対応リゾルバーを見つけ、証明書検証を通過し、鍵を取得して応答を受け取った。通常の運用指標だけなら、展開は成功である。

ところが複数地点の記録を突き合わせると、一台だけが別の鍵設定を受け取っていた。暗号は正常だった。その正常な暗号設定が、端末を一人だけの集団に分けていた。

2024 年 2 月公開の RFC 9540 が重要なのは、この矛盾を仕様の外へ追い出していないからだ。Service Binding レコードによる OHTTP 発見を標準化しながら、発見経路が標的化の経路にもなる条件を記している。したがって運用者は、「対応を広告した」と「プライバシー効果を確認した」を同じ状態にしてはならない。

空の値がサービス選択を左右する

ohttp SvcParamKey の値は、表記上もワイヤ上も空でなければならない。存在そのものが、記述されたサービスを関連ゲートウェイ経由の OHTTP ターゲットとして利用できることを示す。

ただし、その一ビットには選択規則がある。mandatory に含まれる場合、意味を理解できないクライアントは当該レコードを無視する。必須でなければ、OHTTP は選択肢であって強制ではない。複数の SVCB レコードが別々の構成を提示することもできる。

ここで得られる受領証の範囲は狭い。ある DNS 権威が、ある時点・TTL・選択条件で OHTTP 対応を広告した。それだけである。実際に OHTTP が使われたこと、ゲートウェイが到達可能なこと、他の利用者にも同じ鍵が渡ったことは証明しない。DNSSEC で保護されていない平文 DNS なら、経路上の攻撃者が SVCB 情報を除去してダウングレードさせられる。well-known 資源の確認や、暗号化 DNS と DNSSEC の併用は緩和策だが、後段の挙動までは保証しない。

発見されないリレーに誰が責任を持つのか

OHTTP では知識を三つの役割に分ける。リレーはクライアントのネットワーク上の身元と宛先ゲートウェイを見るが、封入された内容は読めない。ゲートウェイは内容を復号する一方、単一取引からクライアントのネットワーク身元を知るべきではない。ターゲットはアプリケーション処理を行う。

RFC 9540 が発見するのはターゲットとゲートウェイであり、リレーの発見は明示的に範囲外である。クライアントは、一般のゲートウェイへ到達できる、または到達可否を照会できる信頼済みリレーを既に持つという前提だ。

この前提は実装注記ではなく統治上の空白になり得る。誰がリレーを選ぶのか。どのログを何日保存するのか。ゲートウェイと同一の事業者、クラウド、法域に属していないか。不正対策のための記録が相関に転用されないか。RFC 9540 に完全準拠しても、これらの問いは残る。

well-known URI は二者が別々にたどる

クライアントはターゲットと同じホストの /.well-known/ohttp-gateway を利用する。サーバーはここから別の場所へリダイレクトできる。しかし、鍵取得時にクライアントが受け取ったリダイレクト URI を、そのままリレーに渡してはならない。

ゲートウェイが利用者固有の値を URI に埋め込み、後でリレーから戻ってきた値を照合できてしまうからだ。リレーは well-known URI から自ら開始し、自らリダイレクトを追う必要がある。全利用者に共通する行き先はキャッシュできても、クライアント固有の経路を引き継いではならない。

監査にも二本の時系列が必要になる。クライアントが設定取得で見た経路と、リレーが封入要求の配送で見た経路である。「最終ゲートウェイ URL」だけを保存すると、個別標的化を見つけるための差分を自ら捨てることになる。

最初の保護通信より前に IP アドレスが見える

クライアントは封入に先立ち、Accept: application/ohttp-keys を付けた GET で鍵設定を取得する。直接取得すれば、ゲートウェイはクライアントの IP アドレスを観測する。

個々の問い合わせを既知の契約者アドレスから切り離すだけなら、それを許容する設計もある。所在地そのものを隠す約束なら矛盾する。また、観測した IP に応じて異なる鍵を返せる点も問題だ。プロキシ経由で取得すればアドレスは隠せるが、新しい観測者と運用責任が増える。

鍵が有効であることと、共通であることも別である。OHTTP 要求は使用した鍵設定によって関連付けられ得る。ある利用者だけに鍵 A、他の全員に鍵 B を渡せば、暗号を破らずに一人の集団を作れる。RFC は共有プロキシによる確認など、一貫性を確かめる方法を推奨する。個別設定を検出したクライアントは、そのゲートウェイの利用を停止し、報告できる。

運用では比較母集団、時間窓、独立観測地点、通常の鍵更新、逸脱時の停止条件を決める必要がある。「鍵を解析できた」は暗号処理の受領証でしかない。「同じ鍵を他者も受け取った」が標的化に関する受領証になる。

DoH のパスも識別子になり得る

Oblivious DoH では dohpath も標的化面である。共通鍵を使っていても、一人だけ違うパスを与えれば、その文字列で識別できる。

クライアントは /dns-query{?dns} のような既知の単一値だけを許可するか、任意の値を別の情報源と比較する。RFC は能力と脅威モデルに応じた抜き取り検査も認めるが、抜き取りで得られるのは検査対象に対する根拠だけである。

DDR と DNR の違いも保持しなければならない。DDR では発見した oblivious DoH サービスに規定の証明書検証が必要である。DNR は DHCP やルーター広告で値を伝え、指定を信頼する根拠が異なる。どちらも固有 dohpath を自動的に排除しない。証明書はエンドポイント名の支配者を示すが、同じ支配者が全員を等しく扱ったことまでは示さない。

成功を九つの受領証に分ける

管理可能な展開は、ohttp の広告、必須性の解釈、DDR／DNR 指定の受容、エンドポイント本人性、鍵設定の取得、鍵・パス・リダイレクトの一貫性、リレーの適格性、取引完了、そして主張するプライバシー効果を別々に記録する。

後段の成功は前段の欠落を埋めない。応答が返っても指定元は正当化されない。証明書が正しくても鍵は共通とは限らない。鍵が共通でもリレーとゲートウェイの独立性は証明されない。プライバシーは複数の観測から導く限定的な結論であって、プロトコル処理の完了フラグではない。

この区別は OHTTP の評価を下げるのではない。何が実現され、どこで責任が途切れたかを説明できるようにする。広告は調査の入口として有用であり、最終判定として使ったときだけ危険になる。

出典