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

Mark Andrews marka at isc.org
Sat Aug 3 01:43:48 UTC 2013


In message <CAEKtLiT9=M1NBfJQ2ormRdQR2UPRjHcX9LznKXSyTZV4TDJ4FQ at mail.gmail.com>
, Casey Deccio writes:
> On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews <marka at isc.org> wrote:
> >
> > In message <51FB9C18.23133.401EA34 at tmorizot.sd.is.irs.gov>, "Scott Morizot"
>  wri
> > tes:
> >> The BIND 9 resolver returns an answer with the AD bit set. Unbound
> >> returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the
> >> only three nameservers I've tested.
> >
> > Version 1.4.8 onwards should validate the zone.  Earlier versions were
> > broken.  http://www.unbound.net/documentation/info_algo.html
> >
> 
> Actually, while unbound has loosened their requirements as per the
> reference above, they are still stricter than BIND--and RFC for that
> matter, though the basis for their strictness is actually lack of
> specification for some circumstances.  There was a recent thread on
> the unbound-users mailing list on just this topic and the same DNS
> name (though I can't seem to get to the site over v4 or v6 at the
> moment to reference it).  RFC 6840 (DNSSEC clarifications) says the
> following, paraphrased from section 5.11:
> 
> - all the algorithms in the DS RRset must be present in the DNSKEY RRset
> - addition algorithms are allowed in the DNSKEY RRset, but not vice-versa
> - the zone RRsets must be signed by all algorithms in the DNSKEY RRset
> - a validator must support any valid path (i.e., don't require that a
> path with all algorithms)
> 
> dfas.mil is violating the third rule above, which could potentially
> hinder some implementations from creating a chain of trust all the way
> to the RRset.  unbound (capable of both algorithms in the DNSKEY
> RRset) is violating the fourth rule above.

The listed requirement is the signer signs with all key algorithms.
This is per instance of the zone.  There is no requirement that all
visible sources of zone have signature for all key algorithms
published in all visible instances of the zone.  There is no
requirement that one apparent source of the zone present a single
instance of the zone only that a single answer comes from a single
instance.

Unless you can see the full contents of a instance (i.e. be able to
transfer the zone) of the zone you cannot check if the signer is
correctly operating or not.  There is no other way.

> The second rule above is what creates the apparent underspecification.
> What about validators that don't support the algorithm with which the
> (extra) RRset is signed? 

The ignore those records.  They DO NOT care if they are there or not.

> Insecure delegations happen at the zone cut, not mid-zone.

Correct.

> A delegation might be "secure" because the algorithm at the DS is
> understood, but if an additional algorithm from the DNSKEY RRset is used
> to exclusively sign an RRset, the behavior is undefined. IMO, the outcome
> would need to be "bogus" (as opposed to "insecure"), but it's simply not
> defined.

Which is why there is a requirement on the signer.  There is no
requirement on the validator to check that the signer did the correct
thing.  If a signer makes this mistake then some validators will treat
the records being signed as good (those that support both algorithms) 
and some will treat it as bogus (those that only support the algorithm
in the DS set).

You would like to see consistancy when rules are not followed.  The
specification does not give that and does not require that.  It is
designed to give consistency when the rules are followed.

In this instance all the records in dfas.mil are signed with algorithm
7.  The DS records are for algorithm 7.  There are algorithm 7 and
8 dnskey records visible.

A validator that only supports algorithm 8 treats this zone as
insecure as there is no DS record which lists agorithm 8.

A validator that only supports algorithm 7 treats this zone as
secure as there is a DS record that lists algorithm 7.  It expects
to see RRSIGs with algorithm 7.

A validator that supports algorithm 7 and 8 treats this zone as
secure as there is a DS record that lists algorithm 7.  It expects
to see RRSIGs with algorithm 7.

If the validator is operating correctly will pass the answers from
this zone.

The operator of the zone is required to wait until all caches are
clear of answers which only contain algorithm 7 records before
publishing a DS record with algorithm 8.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list