要約

  • 草案02は、子がNS・glue・DSの具体的変更を通常のDNS UPDATEで親へ送り、SIG(0)でtransactionを保護し、DSYNCで受信先を見つける仕組みを提案する。
  • 自己署名が証明するのは新しい秘密鍵の所持である。親はKEYをいったんknownに置き、別のbootstrap検証を通して初めてtrustedへ進める。
  • 再bootstrapでは新鍵の検証が終わるまで旧trusted鍵を消してはならない。NOERRORの後も、受付、provisioning、権威公開、resolver観測は別の証拠である。

置き換え処理は、正しい順序を失うと攻撃面に変わる。

draft-ietf-dnsop-delegation-mgmt-via-ddns-02の開始メッセージには、既存KEY RRsetの全削除と新KEYの追加が含まれる。候補鍵自身による署名をその公開鍵で検証すれば、秘密鍵の所持は確認できる。しかし、そこで旧鍵まで先に消すと、攻撃者は認可を得る必要がない。偽の鍵を作り、置換処理を起動するだけで有効な経路を止められる。

草案はKEYを二段階で扱う。受信して自己署名を検査できた段階はknownである。これは「見つけた」「所持を確認した」という状態にすぎない。親が公表した方法で権限の由来を検証し、成功した時だけtrustedになる。新鍵がそこへ到達するまで旧trusted鍵を維持する規則が、bootstrapを削除命令から認可更新へ変える。

この論点は現在進行中だ。DNSOPは8月20日にWorking Group Last Callを始め、9月7日を期限とした。9月4日にはchairが、反対がないだけでは足りず、明示的な支持と建設的な指摘が必要だと呼び掛けた。Geoff Hustonは親側pollingより効率的だとして公開を支持した。Johan Stenstamはunsigned childにも使える点を重視し、自身の実装上の立場を示した。Michael Richardsonは本文から実装できると評価しつつ、KEYとDNSKEY、鍵状態、将来のalgorithm、state machine図を論点にした。いずれも個人の発言であり、WG合意やIETF承認、相互運用を証明しない。

通信自体は新しくない。子はRFC 2136のDNS UPDATEを作り、RFC 2931と3007のSIG(0)でtransactionを署名する。RFC 9859のDSYNCは、親が更新を受けるか、論理的なUPDATE Receiverがどこにあるかを示す。Receiverは親primaryと分離でき、running zoneではなくprovisioning databaseへ要求を渡してもよい。

だから、署名済みpacketと実行権限を同一視できない。Receiverは対象RRsetをNS、glue、DSおよび厳格なKEY操作に絞る。別の認可方式を明示的に採らない限り、子の名前と同名のtrusted SIG(0)鍵だけがその委任を操作できる。さらにCDS/CDNSKEYやCSYNCと同じ内容検査を続ける。pushは親の判断を省略しない。

信頼の出所にも差がある。DNSSEC署名済みの子ならapex KEYをchainで検証できる。子はunsignedでも、権威nameserverが署名済みzoneに属するなら、そのproviderが専用名にKEYを公開できる。小規模な親はmanual確認を選べる。

署名chainがない子では、複数地点、複数時点、複数transportからauthoritative serviceを観測し、提出KEYと一致するかを見る。一貫性はon-path攻撃を難しくするが、registrantの権利を作らない。草案が認証すると述べるのは現在の権威server operatorであり、registrantではない。trustedとは鍵の永久属性ではなく、採用した証明経路に基づくreceiverの判断である。

KEYとDNSKEYも分ける必要がある。DNSKEYはDNSSECのzone署名構造に属する。このKEYはSIG(0) transactionを認証する。管理画面で両方を「DNS鍵」としてまとめれば、custody、rollover、compromise response、scopeの違いが消える。

返答も段階的だ。NOERRORはReceiverがUPDATEを受け入れ、親データの変更が後で期待されるという意味である。provisioning完了、権威公開、TTL消化、resolver到達ではない。REFUSEDはpolicy、rate limit、設定不良の可能性がある。BADKEYは検証用公開鍵がないことを示すが、すべての途中状態は区別しない。無応答ではrequestとresponseのどちらが失われたか分からない。

監査記録には、DSYNCのendpointとpolicy世代、UPDATEのdigestとprerequisite、KEY識別子、bootstrap方式、knownとtrustedの遷移、署名済み応答、provisioning transaction、親serial、公開RRset、TTL後のresolver viewを別々に残すべきだ。service結果はさらに後に置く。

Heng Luの現実層で言えば、記録は観測した範囲を正確に述べる時に役立つ。既知という記録が、信頼を宣言してはならない。draftの公開が採用を宣言してはならない。Receiverの受理が公共DNSを宣言してはならない。この境界を守ることが、署名を権力へ膨張させない条件になる。

情報源