要約

  • DNS Cookieは、要求を送信元アドレス、Client Cookie、過去のサーバー応答に結び付け、オフパスの増幅、偽造、キャッシュ汚染に対して意図的に限定された保護を与える。
  • 有効なServer Cookieは人や永続的な端末を識別しない。複数の利用者がNATアドレスを共有でき、アドレス変更時にはCookieを更新する必要があり、オンパスの観測者は有効期間中に見た値を再利用できる。
  • 運用記録には方式、経過時間、アドレス文脈、anycast検証範囲、再試行結果を残し、アクセス制御、課金、個人単位の制限は別の認証主体に結び付けるべきだ。

監視画面は、Server Cookieが検証できた要求を「認証済みクライアント」と表示する。そのラベルを受けた下流の制御は、レート制限を緩めたり、通信量を特定の契約者へ計上したりする。サーバーが作った推測困難な値を、期待したアドレスから相手が返したのだから、筋は通っているように見える。しかし、そのアドレスは何千人もが共有するキャリアグレードNATの出口かもしれず、組織全体に代わって問い合わせる再帰リゾルバーかもしれない。

失敗したのはCookieではなく、ラベルの範囲である。正しい問いはもっと狭い。この送信元アドレスで、このClient Cookieを使うクライアントが、当該サーバーまたは相互運用するanycast集合から以前に応答を受け取った証拠があるか。これは戻り経路とDNSトランザクションについての主張であり、人の名前、アカウント、権限についての主張ではない。

有効なServer Cookieは以前の交換を裏づける

RFC 9018はDNS Cookieを軽量なトランザクションセキュリティ機構と位置付け、オフパス攻撃者によるサービス拒否の増幅、偽造、キャッシュ汚染への限定的な保護を与える。「限定的」という語は設計上の境界を表す。対象の攻撃者は、被害者とDNSサービスの間の通信を観測できず、受け取っていない値を推測しなければならない。

COOKIEオプションの二つのフィールドは役割が異なる。クライアントは推測困難なClient Cookieを作り、サーバーIPアドレスごとに別の値を使わなければならない。RFC 9018は64ビットのエントロピーを推奨する。これはサーバーが発行するアカウント資格情報ではない。クライアントが選び、サーバーが応答で返す値である。サーバーアドレスごとに分けることで、別のDNSサーバーが対象サーバーの応答を偽装しにくくする。

Server Cookieはサービス側が作る戻り経路のトークンだ。RFC 9018は実質的なメッセージ認証コードとして説明し、Client Cookie、クライアントIPアドレス、規定されたバージョンと時刻のフィールド、サーバーまたは同一anycastアドレスのサーバー集合だけが知る秘密を入力に含める。有効な値が要求で戻れば、そのアドレスにいてClient Cookieを使うクライアントが、以前に値を含む応答を受け取ったという弱い保証をサーバーが得る。

RFC 7873は、そのクライアント文脈と過去に通信したとみなし、送信元を偽装したUDP要求向けの一部防御を省けるとしている。だが、DNSオプションを汎用の本人確認プロトコルにはしていない。有効なCookieは、アカウント、管理端末、限定ビューへの権利、課金責任を証明しない。

運用上の表現も証拠に合わせる必要がある。「この時刻、この送信元アドレス、Client Cookie、検証集合に対してServer Cookieが有効」は検証可能だ。「認証済み利用者」は、プロトコルにない情報を付け足している。

共有アドレスは本人性との対応を壊す

攻撃者がいなくても、NATだけで境界は明らかになる。家庭用ゲートウェイ、企業の出口、キャリアグレードNATは、多数の端末と利用者を一つの公開アドレスにまとめる。Server Cookieがそのアドレスを正しく計算へ取り込んでも、背後の誰がアプリケーション操作を始めたかは区別できない。

RFC 9018は、NAT装置の背後にいるクライアントが公開アドレスの変更を検知できない場合があるとも指摘する。一方、サーバーはNAT装置の公開アドレスを追跡でき、その追跡を防ぐことは仕様の範囲外である。サーバーのネットワーク境界では正しい証拠が、契約者への帰属には粗すぎるという状況が成立する。

Server Cookieを個人別レート制限の鍵にすれば、独立した利用者を一つに束ねてしまう。課金IDにすれば、一時的なネットワーク属性へ長期の責任を負わせる。暗号が破られたのではない。ポリシーが、Cookieの契約に含まれない主体の区別を求めたのである。

移動性は逆方向の誤りを作る。RFC 9018は、リンクをまたぐ端末追跡やIPv6 Privacy Extensionsの回避を防ぐため、クライアントIPアドレスが変わった後にClient CookieやServer Cookieを再利用してはならないと定める。Cookieが新しくなっても、同じ人と端末が正しくプライバシー規則を守っただけかもしれない。Cookieが安定していても、アドレスとプロセスが安定していた以上の本人性は示さない。

一つのアドレスは複数のクライアントを表し、一つのクライアントは正当に複数のアドレスとCookieを使う。永続的な本人性には、その変化を意図的に表現できる別の資格情報とライフサイクルが必要だ。

BADCOOKIEは診断の分岐であり、犯人の判定ではない

無効なServer Cookieには、仕様上いくつもの説明がある。RFC 7873は、値が古すぎる場合、クライアントアドレスまたはClient Cookieが変わった場合、anycastクラスタの構成が不整合な場合、偽装が試みられた場合を挙げる。サーバーは無効なServer Cookieがなかったものとして要求を処理する。結果だけでは原因を一つに決められない。

BADCOOKIEは回復手順を作る。クライアントは応答に含まれる新しいServer Cookieで再試行する。その新しい値でもBADCOOKIEが返れば、anycast集合内の共有秘密や生成方式のずれが具体的な仮説になる。RFC 7873は次にTCPで試すよう求め、TCPのトランザクション特性を代替の根拠として使う。

重要なのは順序だ。古いCookieの年齢と方式、両端から見えたアドレス、anycastメンバーまたは検証範囲、新しい値、次の応答、TCPへ切り替えた結果を一つの記録にする。無効Cookieをすべて「攻撃」と数えると、通常の期限切れ、移動、展開のずれ、敵対的通信を分ける材料が消える。

秘密の更新でも同じ証拠が必要だ。RFC 9018は段階的なローテーションを要求する。全メンバーが新しい秘密を学習して検証可能になってから発行を始め、移行中は古い秘密も受け入れる。一台だけ早く、または遅く切り替われば、anycastの到着先によって有効と無効が交互に現れる。クライアントを攻撃者扱いすれば、実際の制御面の不整合が隠れる。

既存のDNS防御は引き続き必要である

DNS Cookieは応答照合を補完し、置き換えない。RFC 5452は、DNSの信頼規則を適用する前に、応答の送信元と宛先アドレス、宛先ポート、Query ID、問い合わせ名、クラス、タイプを未処理の問い合わせと照合するよう求める。送信元ポートとQuery IDも予測困難でなければならない。各要素はオフパス偽装の難度を上げるが、利用者の身元にはならない。

それぞれが答える問いは近いが別物だ。応答照合は、返答が実際に送った問い合わせへ対応するかを確認する。応答で正しいClient Cookieが返れば、クライアントが選んだサーバーアドレスとの弱い関連が得られる。要求の有効なServer Cookieは、送信元文脈へ以前に応答が戻った証拠になる。どれも人を識別せず、単独では機密性も提供しない。

RFC 6891は運搬面を定める。EDNSはホップごとの拡張であり、OPTレコードは一つの質問と応答の制御情報を運ぶ。DNSデータは持たず、キャッシュ、転送、マスターファイルへの保存をしてはならない。COOKIEはDNSトランザクション処理のオプションであり、恒久的な利用者台帳ではない。

オンパスの境界も明確である。平文DNSを観測できる者はServer Cookieを取得し、有効期間中にそのクライアントへ対して再利用できる。サーバー側MACは、秘密を知らないオフパス攻撃者が任意の有効値を作ることを難しくする。通信中のCookieを暗号化したり、経路上で送信できる全主体を認証したりはしない。

文脈を失わない受領証を作る

Cookieの判断ごとに、サーバーから見た送信元アドレス、取得できる場合はクライアントから見たアドレス、Client Cookieの不可逆な参照、Server Cookieの方式と年齢、検証結果、anycast検証集合、再試行の順序、TCPフォールバックの結果を残す。秘密そのものは記録せず、秘密の世代と各メンバーの展開状態を別に保存する。

サービスがアカウントや端末も認証するなら、その主体を独自の方式と時刻で記録する。どの認証済みセッションが、どの期間に、どのDNS問い合わせを生んだのか。共有リゾルバーやNATが介在したとき、どの程度の不確実性があるのか。この結び付きは明示される必要があり、存在しない場合にCookieで補ってはならない。

警告文も証拠に従う。「戻り経路トークンが有効」は正確である。アドレスと時刻を添えれば、「この送信元文脈へ以前に到達した」も成立し得る。「既知の顧客」「信頼済み端末」「認可済み利用者」には別の事実が必要だ。

参考文献

  1. RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
  2. RFC 7873 — Domain Name System (DNS) Cookies
  3. RFC 5452 — Measures for Making DNS More Resilient against Forged Answers
  4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0))