BIND9 DNSSEC algorithm rollover for inline-signed zone

[Tony Finch]

Mark Andrews <marka at isc.org> wrote:
> Sebastian Wiesinger <sebastian at karotte.org> wrote:
> >
> > Thank you for explaining this for me. I was reading RFC6781, which I
> > now realize is probably outdated in this regard so I was a bit
> > confused.

RFC 7583 (DNSSEC Key Rollover Timing) is also worth reading.

> > > Once named has completed signing the zone with the new algorithm
> > > and all the slaves have the fully signed zone and the caches have
> > > expired any RRsets which are only signed with the old algorithm you
> > > can add DS records for the new algorithm for the zone.
> >
> > This only applies when I change the DS record, right? I assume that I
> > can add the new one instantly and remove the old one later when all
> > caches have expired the old data.
>
> There are always timing considerations with DNSSEC.  You prepublish
> DS records or you have multiple KSKs.  You have multiple signatures
> or you have multiple ZSKs.  It's all about having what you need to
> validate available regardless of when the records are learnt or from
> where.

It is (was?) my understanding that validators are supposed to check that
the DNSKEY RRSIGs include at least all of the algorithms present in the DS
RRset. This is to protect against RRSIG-stripping downgrade attacks.

However RFC 6840 (DNSSEC Clarifications) section 5.11 says

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.  A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.

which is weaker than I thought it was.

I thought the algorithm rollover process is required to be: introduce new
ZSK and KSK and sign the zone; wait for old records to expire; flip the DS
from old to new; wait for old DS to expire; delete old ZSK and KSK and
RRSIGs. A double-DS algorithm rollover will cause your zone to go bogus.

This page has a pretty good description of the whys and wherefores, what
Unbound's validator requires, and what its algorithm rollover bug was:
	https://unbound.net/documentation/info_algo.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or
moderate. Showers. Good.