要約

  • DNS Cookiesは、最初の往復通信を限定的な到達性の証拠へ変える。正しい二つのトークンを伴う次の要求は、経路外から送信元を偽る攻撃者には作りにくい。
  • RFC 7873が交換手順を定め、RFC 9018が16バイトのバージョン1 Server Cookieを標準化したことで、異なる実装からなるanycast群でも同じ状態を検証できるようになった。
  • これは身元確認でも暗号化でもない。経路上の観測者はトークンを見られ、NATは複数の端末を一つの公開アドレスにまとめるため、レート制限などの防御は引き続き必要になる。

最初の問い合わせには、アカウントも証明書も事前共有鍵もない。届くのはUDPデータグラムであり、送信元アドレスが正しい保証はない。クライアントはEDNSのCOOKIEオプションに8バイトのClient Cookieを入れる。対応サーバーはその値を返し、自ら生成したServer Cookieを添える。次の問い合わせでクライアントは両方を提示する。

二度目のパケットには、ごく短い履歴が刻まれている。Server CookieはClient Cookie、サーバーから見たクライアントアドレス、サーバーだけが持つ秘密に依存する。経路外の攻撃者は被害者のアドレスをIPヘッダーへ書けても、そのアドレスへ返された直前の応答は通常見られない。したがって、対応するトークンを持てない。サーバーが得るのは「このアドレスとClient Cookieの組み合わせとは以前通信した」という弱い証拠である。クライアント側も、期待したClient Cookieを返さない応答を捨てられる。

ここで身元が確定するわけではない。家庭用ルーター、通信事業者のNAT、企業の境界装置は、多数の端末を一つの公開アドレスの後ろに置く。正しい場所にいる侵害済み端末は依然として攻撃できる。経路上で平文DNSを見られる相手はcookieを複製し、有効期間中に再利用できる。DNS Cookiesは問い合わせ名を隠さず、利用者や組織を認証せず、DNSSECを置き換えない。証明するのは、返り道が一度成立したということだけだ。

それでも価値があったのは、UDP DNSが送信元詐称を増幅へ変え得たからである。短い質問が、偽られた被害者アドレスへ大きな応答を送らせる。偽の要求が再帰問い合わせやDNSSEC検証の負荷を発生させることもある。逆向きには、偽応答が正規応答より先に到着し、キャッシュへの混入を狙う。DNSSECはデータを認証し、TSIGは鍵管理を前提に強いトランザクション認証を行う。ポートやIDの乱数化は盲目的な推測を難しくし、応答レート制限は出力量を抑える。DNS Cookiesは、サーバー側の顧客台帳を作らずに返り道の証拠を加えた。

2016年5月のRFC 7873は、COOKIEをEDNSオプションコード10として定めた。Server Cookieを知らない段階では8バイトのClient Cookieだけを送り、学習後は8〜32バイトのServer Cookieも加える。最初の仕様は具体的な生成方法を実装に委ねていた。サーバーは送信元、Client Cookie、秘密から値を再計算できるため、クライアントごとの状態を保存する必要がない。

状態遷移は段階的導入を想定している。未対応サーバーはオプションを無視する。対応サーバーがClient Cookieだけを受け取った場合、ポリシーに応じて破棄、BADCOOKIE、通常応答のいずれかを選べる。応答するなら、次の段階へ進むためのServer Cookieを返す。不正な長さはFORMERRとなる。期限切れや不正なServer Cookieは、持っていない場合と同じ扱いになる。有効な値があれば、送信元を偽ったUDPだけを対象とする防御を緩められるが、一般的な信頼を与える理由にはならない。

BADCOOKIEは単なるエラーではなく、再同期の遷移である。応答のClient Cookieが一致すれば、クライアントは新しいServer Cookieを保存して再試行できる。受け取ったばかりの値が再び拒否されるなら、TCPへ切り替える。繰り返しは攻撃だけでなく、同じanycastアドレスのノード間で秘密や生成方法が食い違っている兆候にもなる。

NATがあるため、Server Cookieは公開アドレスだけに結び付けられない。一台の端末が取得した値を、同じ出口の全端末が利用できてしまうからだ。Client Cookieも計算に入れれば、サーバーは利用者別の記録を持たずに流れを区別できる。ただし、これはネットワーク上の区別であって個人の特定ではない。

Anycastは別の問題を露呈した。同じサービスアドレスへの連続した問い合わせが、異なる機械や異なるDNS製品へ届くことがある。RFC 7873は秘密の共有を勧めたが、入力からServer Cookieを作る手順までは統一しなかった。同じ秘密を持つ二つの実装が、互いの値を検証できない場合があった。通常の経路変更が不正cookieに見えてしまう。

2021年4月のRFC 9018は、バージョン1 Server Cookieを16バイトに固定した。1バイトのバージョン、3バイトの予約領域、4バイトの時刻、8バイトのSipHash-2-4結果からなる。8バイトのClient Cookieを合わせたCOOKIEオプションは正確に24バイトである。ハッシュ入力にはClient Cookie、構造フィールド、クライアントIP、Server Secretが入る。IPは検証に使われるが、cookieそのものには格納されない。

時刻は再利用の範囲を区切る。RFC 9018は過去1時間以内の値を受け入れ、anycast間の時刻差のため未来方向へ5分を許容し、30分を超えた値は更新するよう勧める。すべての実装が同じ設定だという意味ではない。トークンは期限付きであり、経路上の観測者には利用可能な期間も見える、という設計上の境界である。

秘密の更新も三段階の運用になった。まず新しい秘密を全ノードへ配り、旧秘密で発行しながら両方を検証する。次に新秘密で発行し、旧値の検証は続ける。クライアントの更新を待ってから旧秘密を廃止する。アルゴリズムの統一だけでは足りない。時計、配布、移行段階がそろって初めて、anycast群は一つの終端として振る舞う。

RFC 9018はClient Cookieの助言も改めた。サーバーIPごとに別の64ビット乱数を用い、クライアントIPが変わったら以前のcookieを再利用しない。安定した識別子が端末を複数ネットワークにまたがって追跡するのを防ぐためだ。NAT配下の端末は公開アドレスの変化を検知できないことがあり、その残余問題は対象外とされた。

DNS Cookiesの歴史は、DNSに身元が持ち込まれた物語ではない。証拠が、実際に支えられる主張の大きさへ合わせられた物語である。最初の往復は意図を証明しない。ただ、応答を受け取っていない経路外の相手に、次の送信元詐称を難しくする。RFC 7873が交換を設計し、RFC 9018が異種anycast環境で成立させた。実効的な制御点は、クライアントの再利用方針、サーバーの応答方針、時計と秘密の共同管理にある。

出典