要約

  • RFC 3445は新しいKEYをDNSSECのプロトコル値3に限定した。DNS問い合わせは内部サブタイプを指定できず、署名もRRset全体を対象にしたためである。
  • 権威側は旧値の公開を止める一方、読み手は検証中に旧レコードを保持する。先に除去すれば署名対象が変わり、キャッシュ間の不一致も起こり得た。

万能の引き出しには仕切りがなかった

RFC 2535のKEY RDATAはFlags、Protocol Octet、Algorithm、Public Keyから成る。1は電子メール、2はIPsec、3はDNSSEC、4はTLS、5〜254は割り当て可能、255は任意のプロトコルを意味した。既存のDNSを公開鍵の棚として再利用する構想である。

しかし問い合わせが指定できるのはKEYという型までだった。特定用途だけをサーバーに要求できず、同じ所有者名のRRsetを丸ごと受け取る。DNSSEC署名も用途別の一部ではなく、集合全体を覆った。用途は複数でも、取得と証明は一単位だった。

2002年12月のRFC 3445は、限定的な実験配備で見えた問題から境界を引いた。原文、RFC Editor記録、Datatracker、履歴、参照、被参照文書、正誤情報は文書上の事実を示すが、配備数や実装の正しさまでは示さない。

同じ鍵形式でも、壊れ方は同じではない

文書は六つの差を挙げた。目的、管理者、認証規則、権威サーバーが応答へ含める理由、リゾルバーの扱い、障害・侵害時の結果である。DNSSEC鍵はDNSデータの完全性を支える基盤だが、アプリケーション鍵はDNS自身に特別な意味を持たない。

混在RRsetは無関係な用途が増えるたび肥大化し、応答量と署名更新を連動させる。さらに、プロトコル欄を無視する実装は、侵害されたアプリケーション鍵をゾーン鍵と誤認し得る。暗号が正しくても、誰に何を証明させるかをコードが間違えれば安全にはならない。

RFC 3445は新しい権威KEYを値3に限定し、ゾーン鍵を表すbit 7以外のフラグを予約した。1、2、4、255と旧来の空き範囲も閉じ、新規割り当てはStandards Actionに限った。RFC 2930、RFC 2931、RFC 3007に関わるDNSSEC用途は残るが、host/userの区別は失われた。

使わないことと、検証前に捨てること

非3値をDNSデータ認証へ使ってはならない。それでも読み手は署名検証が終わるまで、そのレコードをRRsetの一員として保持すべきだった。署名者が覆ったのは元の全集合である。途中で一件を落とせば別のバイト集合を検証し、SIGは失敗する。キャッシュごとに除去方針が違えば、同じ名前の署名集合が分裂する。

権限を否定する判断と、証拠を構成するデータを保存する判断は別である。新規生成を閉じ、移行に必要な読み取り能力を残し、旧値には意味上の権限を与えない。RFC 3445は「全部受け入れる」と「全部消す」の間に、段階的な廃止を示した。

後のRFC 4033、RFC 4034、RFC 4035は2535系を置き換え、DNSKEYを用いた。用途別にはSSHFP、CERT、TLSAもある。これは後年の分離を示す文脈であり、単一の因果関係の証明ではない。IANA DNS Parametersが証明するのも登録状態までである。

共有すべきなのは形式ではなく境界

Heng Luの現実の層は、登録値、署名の妥当性、管理権限、配備コード、結果を分ける。KEYへ一緒に入れても、その違いは消えない。稼働コード優先の観点では、限定配備が抽象設計を修正した点が重要だ。問い合わせ、署名、キャッシュが実際に払う費用は、整った形式図より強い反証になった。

最小初期仕様からは、目的、検証、障害結果を共有する最小単位だけを共通化する原則が読める。DNSは自らの基盤鍵を定義できるが、あらゆるアプリ鍵の統治者になる必要はない。これは編集上の解釈であり、著者個人の意図を断定するものではない。

一つのワイヤ形式は一つの信頼領域ではない。問い合わせ、署名、キャッシュが対象を一組として動かすなら、その組の境界はすでにセキュリティと責任の境界になっている。

出典