要約

  • 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 環境で成立させた。実効的な制御点は、クライアントの再利用方針、サーバーの応答方針、時計と秘密の共同管理にある。

出典