Re: [dnsext] DNSSEC, robustness, and several DS records

[Brian Dickson <[e-mail]>]

On Wed, May 11, 2011 at 9:28 PM, Mark Andrews <[e-mail]> wrote:

>
> In message <[e-mail]>, Francis Dupont
> writes:
> >  In your previous mail you wrote:
> >
> >    Note that the text in RFC 4509 has a SHOULD, not a MUST. The fact
> >    that the BIND and Unbound people treat it as a MUST seems like a
> >    bug.
> >
> > => I don't understand how the SHOULD can be interpreted in order to
> > avoid the "bug" (:-). Seriously you can disagree with RFC 4509
> > but not about the way it has to be implemented, i.e., your concern
> > is not about what it should be...
> >
> > Regards
> >
> > [e-mail]
> > _______________________________________________
> > dnsext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsext
>
> Agreed.  You are either configured to follow the SHOULD or not and
> the default is to fail.  Now not having a switch to turn it off
> means you don't have a work around once you discover that DS is
> wrong which requires contacting the administrators for the zone as
> they are the only ones that can tell you whether it is wrong or you
> are under attack.  You can make a educated guess without contacting
> the zone administrators.
>
> Mark
>
>
There are subtleties in the logic for following RFC 4035, which RFC 4509
kind of glosses over with its "SHOULD" recommendation.
(IMHO, the "glossing over" is what creates the "bugs", when RFC 4509 is
looked at in isolation, without considering RFC 4035.)
When both 4035 and 4509 are taken together, those nuances become more
obvious. While there is room for different interpretations, some/most of
those lead to avoidable problems.
BTW - the motivation here is as follows: encode as much logic which is
unambiguous as possible, where that logic does not lead to weakness to
downgrade attack in the absence of significant operator error.
Encoding the "educated guess" into the resolver software minimizes the need
for resolver operator intervention to cases that can't be disambiguated.

Here's a fundamental arithmetic thing: In order for a SEP to be validated,
the DS record has to match all of the Key Tag, the Algorithm, AND the Hash
of the DNSKEY. (NB - both the Key Tag and the Hash depend on the Algorithm.)
So, two DS records with the same Key Tag, but different Algorithms, CANNOT
match the same DNSKEY. (Ditto for same Algorithm/different Key Tags.)

So, the important question is, should the "SHOULD" in RFC 4509 apply:
- Only to DS RRs that (appear to) refer to a single DNSKEY?
- Only to DS RRs which share an Algorithm?
- To all DS RRs without looking at Algorithm or Key Tag?


When there are two different algorithms, given that we (should) treat all
algorithms equally, I'd argue that this is a case where RFC 4509 should NOT
apply, IMHO.
This was the situation that Stephane experienced, FYI, although in his case
the values for Key Tag happened to still match. The separation by Algorithms
would have prevented the "bug" from resulting in "Bogus" / "Unknown" from
being the validation result.

I'd suggest that the most likely scenarios to be seen in production networks
will be DS sets that include both SHA-1 and SHA-256 for the same DNSKEY (and
thus algorithm), and possibly also additional DS record(s) with only SHA-256
on additional DNSKEY(s).

BTW - the reason for having one DS pair with SHA-1+SHA-256 (for one DNSKEY)
and another DS with SHA-256 ONLY (for a second DNSKEY), is that the
following properties apply:
- the SHA-256-ONLY DS *should* only get "touched" when there is activity on
the corresponding DNSKEY, and what doesn't get "touched" is unlikely to be
"broken". RRSIG validity is orthogonal to "breaking" the content of the
DNSKEY and its relationship to the parent's DS record.
- the DS with both SHA-1 and SHA-256 involves synchronized data, on two DS
records and a DNSKEY record. If the DNSKEY record is updated, and the DS
record for SHA-1 is updated but the DS record for SHA-256 is not, this would
be indistinguishable from a downgrade attack.

When you combine the two bullet points, and you get:
- fat fingers can break a single DNSKEY's validation modulo RFC 4509, but is
much less likely to invalidate both DNSKEYs if both types (SHA-256 only and
SHA-256+SHA-1) are present.

Since the attack vectors do not involve the DS sets directly, the presence
of DS records for a given algorithm that do not include SHA-256, suggests
operator error or deliberate choice, and alongside different algorithms with
SHA-256 (with or without SHA-1), those DS records of SHA-1 only should not
be ignored.
It is still more secure to have the method of implementing RFC 4509 be:
(0) validate the DS RRSET via its RRSIG(s).
(1) partition the DS RRSET into Algorithm subsets;
(2) for each Algorithm, if both SHA-256 and SHA-1 are present, suppress the
SHA-1 records
(3) do the rest of 4035 using the resulting DS RRSET (using whatever local
policy is, e.g. either require all Algorithms to validate, or require any
Algorithm to validate)

IMHO, of course.
Brian