[ Quoting <d...@dotat.at> in "[DNSOP] Error in rfc4641bis - chang..." ] > This is horrifically late, I'm afraid - dunno if it's too late to fix it > before publication...
This is indeed pretty late in the game... > There is a problem in the procedure described in section 4.3.5.1. In the > pre-publication phase the following things happen: > > The new operator sets up a copy of the zone signed with new keys, with an > NS RRset pointing at the new servers, and a DNSKEY RRset containing both > old and new public keys, signed with both old and new KSKs. > > The old operator adds the new public keys to the DNSKEY RRset and the new > KSK signature, and updates the NS RRset to include the new servers as well > as the old ones. > > This change of name servers is wrong! It can lead to validation failures > as follows: > > A client has a cached copy of the old DNSKEY RRset. They do a lookup at an > old server (say, www.example AAAA) which validates fine since it is signed > with the old key. As a side-effect it gives them an updated NS RRset which > includes the new servers. They do a second lookup at a new server (say, > www.example A) which is signed which the new key - but the client cannot > validate it because it doesn't have the new DNSKEY RRs. I think you're right :( > There is a simpler procedure for change of operator, which only requires > operators to be able to import extra DNSKEY RRs - the same for both the > old and the new operator. It does not require cross-signing as described > in rfc4641bis, and it does not require either operator to host NS records > pointing at a competitor. Isn't this? https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-04 Section 3.1 Regards, -- Miek Gieben http://miek.nl
signature.asc
Description: Digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
