Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

[Mark Andrews]

In message <51FBAD70.9183.445A9DB at tmorizot.sd.is.irs.gov>, "Scott Morizot" writes:
> On 2 Aug 2013 at 22:25, Mark Andrews wrote:
> > In message <51FB9C18.23133.401EA34 at tmorizot.sd.is.irs.gov>, "Scott Morizot" wri
> > tes:
> > > Hello all,
> > > 
> > > I ran into an interesting situation resolving dfas.mil. It appears that 
> > > they have attempted to roll their ZSKs to algorithm 8 while leaving their 
> > > KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs 
> > > for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for 
> > > each record set in the zone MUST include at least one RRSIG for each 
> > > algorithm. (The distinction between KSK and ZSK is an operational 
> > > convenience and not part of the standard, per se.) The relevant excerpt 
> > > from Section 2.2 of RFC 4035:
> > > 
> > >    There MUST be an RRSIG for each RRset using at least one DNSKEY of
> > >    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
> > >    itself MUST be signed by each algorithm appearing in the DS RRset
> > >    located at the delegating parent (if any).
> 
> > Because the requirement is *only* on the signer.  You will note
> > that the validator is NOT required to check for this as part of the
> > list of things it is supposed to check for and that is a deliberate
> > design decision.  If the signer follows this and the timing rules
> > the zone will not be treated as bogus.  The unbound developers
> > didn't realise this initially and added unspecified checks to their
> > validator.
> 
> I hadn't noticed the differences between 2.2 and 5.3. Interesting. So you 
> can have signing errors (at least according to the standard) that don't 
> result in validation errors.

The point of 2.2 was to ensure that the necessary RRSIGs were all
generated so that it doesn't matter what combination of algorithms
the validator supports.  A validator only requires a single signature
to exist for the RRset to validate.  Yes this is asymetric but it
allows DNSSEC to work with caches getting answers from different
versions of the zone.

Failure to follow 2.2, unless you know exactly what you are doing,
will result in some validators treating the answers as bogus.
Writing down those rules would have been extremely complicated and
the WG decided to apply the KISS principle.

Note even if you think you are talking to the master server you
may be talking to a slave which has a older copy of the zone.
There is *no* way to check if records being return are coming
from the same version of the zone that signed the DNSKEY RRset.

Mark

> Thanks,
> 
> Scott
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org