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

[Shane Kerr <[e-mail]>]

Mark,

At 2016-11-16 08:39:37 +1100
Mark Andrews <[e-mail]> wrote:

> In message <[e-mail]>, Shane Kerr writes:
> > 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-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.

Sorry for being stupid and ignorant here, but again, is there an RFC
which says you need multiple signatures?

I understand that you need multiple signatures on the DNSKEY RRset
itself, but surely you don't actually need to sign the whole zone with
multiple signatures? Once I am sure that every validator has the DNSKEY
RRset with the old and the new DNSKEY ZSK, then I should be able to
choose either ZSK and use that to sign, right? Why is this different in
an algorithm roll versus a normal roll?

> > 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.

Sorry, I'm confused. So the algorithm used by the DS has to sign the
whole zone? Does that mean that Unbound and Verisign DNS had correct
behavior and it is now broken? Does that mean that BIND is broken? 

So confused...
 
> > 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.

Mark, I certainly encourage you to not worry about broken resolvers in
your own systems. I don't for my own vanity domains.

But surely you can see how this might not be acceptable to other
people, right? Surely? Like people may actually have reasons why they
want to make sure their sites are available to as many people as
possible? Surely?

> 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.

Again, I am confused.

If a validator says "I only support algorithm A", then what reason is
there to send it signatures for algorithm B?

I can't think of a good reason not to filter RRSIGs, although I fully
admit that my imagination may just not be up to the task.

Cheers,

--
Shane