Re: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

[Shane Kerr <[e-mail]>]

Dan,

At 2016-11-15 12:41:01 +0000
Dan York <[e-mail]> 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