要約

  • RFC 2065はDNSリソースレコードに検証可能な証拠を結び付け、配送を担うサーバーを当然の信頼主体とせずに、リゾルバーが署名済みデータを判断できるようにした。
  • 旧来のサーバーもKEY、SIG、NXTを保存して返せたが、署名の自動付加、CNAME、委任境界、ADとCDの扱いには、より完全な実装が必要だった。
  • 署名が保証したのは公開データの出所と完全性であり、問い合わせの秘匿、利用者別のアクセス制御、解決後のホストの正当性ではなかった。

キャッシュサーバーから住所レコードが届いた場面を考える。そのサーバーは配送を支配しているが、住所を宣言する権限まで持っているとは限らない。RFC 2065が切り離したのは、この二つの役割だった。サーバーは応答と暗号学的証拠を運び、セキュリティー対応リゾルバーが署名を確かめる。

RFCは、データ出所認証に使うゾーン鍵はゾーンに属し、そのコピーを保持するサーバーに属するのではないと説明した。サーバーの侵害は、応答の欠落、再送、停止を引き起こせる。それでも、攻撃者が新しい有効な署名を作る秘密鍵を自動的に得るわけではない。配送経路への侵入と、主張を正当に署名する能力は別物になった。

三つのサービスを一つの「安全」に畳まない

RFC 2065は、公鍵配布、データの出所認証と完全性、任意のトランザクションまたは要求認証を区別した。DNS交換が一度成功しただけでは、三つすべてが証明されたことにはならない。

KEYリソースレコードは公鍵をDNS名に関連付けた。リゾルバーには、信頼できる方法で事前に設定した少なくとも一つの開始鍵が要る。そこから署名付き鍵をたどって安全なゾーンを検証する。信頼が消えたのではなく、開始点と検証経路が観察できる形になった。

SIGはRRsetに対する中心的な証拠だった。対象レコード型、署名者、アルゴリズム、元のTTL、署名の開始時刻と失効時刻、署名そのものを保持する。有効なSIGが支持するのは、指定期間内の特定RRsetの出所と非改変である。同じパケットに入っているだけの別レコードまで認証するものではない。

NXTは、名前が存在しないこと、または存在する名前に特定の型がないことを証明するためのレコードだった。後年のDNSSECは仕組みを変更したが、肯定回答と認証済み不存在には別の証拠が必要だという境界は既に明白だった。無応答は署名された否定ではない。

任意のトランザクション署名にも独自の範囲があった。メッセージの送信元を認証しても、その中の全リソースレコードのゾーン由来が認証されるわけではない。通信の相手と、データを権限をもって公開した主体は、別々に検査する必要がある。

普通のサーバーは有用な運び手になれた

RFC 2065は、出所認証のために新しい輸送プロトコルを作らなかった。既存のDNS形式に新しいリソースレコード型を加えた。未知の型でも正しく保存し取得できる実装なら、暗号検証を理解しなくても移行経路の一部になれた。

その互換性には問い合わせ回数という費用があった。対応サーバーなら関連署名を応答へ自動的に含められる。非対応サーバーからは、リゾルバーが名前にあるすべてのSIGを別途要求し、目的のRRsetを覆うものを自分で選ばなければならない場合がある。追加の往復によって段階的導入を可能にしつつ、旧ソフトウェアを偽の認証局にはしなかった。

ただし完全な透過性ではない。CNAMEは明示された例外で、従来のサーバーが別名を先に追跡すると、元の名前のセキュリティーレコードを返せないことがあった。RFCはサーバー適合性を最小と完全に分けた。最小適合はKEY、SIG、NXTの保存、取得、ゾーン転送を含む。完全適合には適切な応答構築、署名の自動付加、別名と委任点の処理、ADとCDビットが加わる。

ADは応答サーバーが含まれるデータを検証したことを示した。CDは、問い合わせ側が自ら暗号検査を行うため、上流での確認前のデータも受け取る意思を伝えた。旧実装では両方がゼロになる。ゼロは互換的な輸送状態であって、認証済みという判定ではない。

TTLと署名には別の時計があった

DNSキャッシュのTTLは時間とともに減るが、署名対象の値を変えれば署名は壊れる。RFC 2065はSIGに元のTTLを記録し、署名開始と失効を別に持たせた。リゾルバーは作業中のTTLを短くできても、署名された元のTTLより長くはできない。キャッシュにデータが残っていても、期限切れ署名を証拠として扱えない。

したがってリゾルバーの時計も検証依存性になった。時計を巻き戻せば、古い署名が再び有効に見える恐れがある。鍵管理、署名期間、サーバーの可用性、キャッシュ規則、時刻源、本地の受理方針はそれぞれ別の管理面を持つ。一つの成功応答を万能な緑色ランプにはできない。

公開データの真正性には明確な外側があった

RFC 2065は非目標を率直に書いた。DNSデータは公開され、すべての問い合わせ者に同じ答えを返すものとされた。利用者ごとの権限を定めるアクセス制御リストは追加していない。問い合わせと応答を隠す機能もなく、機密性には当時開発中だったIPsecのような別の通信路が必要だった。

正しい検証結果もDNSレコードの境界で止まる。信頼できる住所回答は、その住所を現在使う機械が正当に認可されたことを保証せず、その後のパケット盗聴や偽造も防がない。署名は一つの不確実性を狭めるが、アプリケーション経路全体を信頼済みに変えない。

最初の仕様は最終版ではなかった

RFC 2065はProposed Standardであり、普及の証明ではない。IETF Datatrackerには1994年から1996年の草案と1997年1月の発行履歴が残るが、導入事業者数までは示さない。1999年3月のRFC 2535は、初期実装の経験と潜在利用者の要望を取り込んだと説明してRFC 2065を置き換えた。2005年にはRFC 4033、4034、4035がその世代を置き換えた。

形式や委任の仕組みは変わっても、責任分離は残った。署名済みデータが出所と完全性の証拠を運び、バリデーターがトラストアンカーと本地方針を適用する。中継者はパケットを運ぶだけで自動的にセキュリティー権威にはならず、機密性は別の問題である。

Lu Hengの「最小初期仕様」という後年の視点から読むと、RFC 2065は共有すべき安全規則を本地で検査できる対象に集中させ、周辺の不均一な導入を許した例に見える。これはEastlakeとKaufmanの歴史的意図を証明するものではなく、本稿の編集上の解釈である。それでも、共通層が有効性の条件を明示しながら、証拠の運び手に全員の判断権まで与えない設計の価値を示している。

出典