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-crypto-algs/ > 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)? 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: 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. :) ---- 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. 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
pgpugFu8uMfxy.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
