In message <20161116000530.19ed4...@pallas.home.time-travellers.org>, Shane Kerr writes: > Dan, > > At 2016-11-15 12:41:01 +0000 > Dan York <y...@isoc.org> wrote: > > The draft is at either of: > > > > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-cryptoalgs/ > > https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 > > > > Please send any comments to the list or to us as authors. > > > > I also am maintaining this over in Github at: > > https://github.com/danyork/draft-deploying-dnssec-crypto-algs If you > > are a Github user you are welcome to file an issue there or send text > > in a pull request. > > > > Regardless, we'd just like any feedback (even if to say that it looks > > good). > > I'm curious about this section: > > Note that the key and signatures with the new algorithm will need to > co-exist with the existing key and signatures for some period of > time. This will have an impact on the size of the DNS records. > > [NOTE(OS): Shouldn't we just update the language that requires the > resolver to be so strict and finally be done with this requirement? > Or just give a recommendation in the paragraph on resolver here?] > > One issue that has been identified is that not all commonly-used > signing software releases include support for an algorithm rollover. > This software would need to be updated to support rolling an > algorithm before any new algorithms could be deployed. > > Is there an RFC which says that you have to have multiple signatures? > In principle, shouldn't it be possible to (for example) add a new > DNSKEY record of a ZSK with a new algorithm, wait until you are sure > that all resolvers have the new DNSKEY, and then start signing using > only that key (as for a usual roll)?
You either have double signature (new alg + old alg) or you go insecure. Adminstrators choice. Remember that you have to have the new signatures and DNSKEYs in place before the DS is published for the new algorithm and you need to keep the old signatures and DNSKEYs in place after the DS for the old algorithm is removed. > So there would indeed need to be two copies of the key, but not double > signature, right? > > I'm not sure if this is ever possible to do for a KSK roll, but honestly > that doesn't matter too much since extra signatures on the DNSKEY > RRSET is not going to affect much traffic in a usual case. > > ---- > > A possibly more important concern is that the RIPE NCC did an algorithm > roll last year, and discovered that Unbound and Verisign DNS require > that the algorithm used by the DS be used to sign the entire zone - not > just the DNSKEY RRSET: That was always required. > https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over > > I think this deserves special merit and probably mention in the draft, > because it means that you have to do both the KSK and ZSK roll > together. The root cause of this is probably considered a bug in the > Unbound and Verisign DNS software and has been fixed... but also > consider that Unbound is a fairly popular DNS software and likely to > have lots of old versions lying around. That means basically that > unless you don't care about breaking a large portion of the Internet we > are stuck with this limitation. :( > > Of course, rolling to a brand new algorithm (post-2015) that arrives in > the future should be fine, since it will only be implemented in newer > versions of the software which support rolling properly. :) I'm not worried about old versions with broken validators. Let them break. When the few reports come in tell them to upgrade to a current version. To work with those old, non RFC compliant, versions you have to publish RRSIGs before you publish DNSKEYs and ISC is not going to hack named to support such behaviour. They don't interoperate and should have CVEs listed against those versions. > ---- > > Finally, mostly as a whine, it's a pity that RFC 6975 forbids > authoritative servers from filtering RRSIG. From a client point of view > this would have been a real motivator to including this information, > since an authoritative server could provide the best signatures > possible (smallest/fastest/most secure/patent-free/whatever), and ONLY > those signatures. There are good reasons not to filter RRSIGs. If validators want to only use alg A when alg A and alg B are present in the DS records they are free to write a validator that supports that. > As it is now, I doubt many (any?) resolvers actually include this > option since it will just add pointless bytes to query packets. If > clients included this it would be of great help to zone owners and > authority server operators in deciding whether a new algorithm is > deployable. :( > > Cheers, > > -- > Shane > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
