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

[Brian Dickson <[e-mail]>]

On Wed, May 11, 2011 at 4:22 PM, Francis Dupont
<[e-mail]>wrote:

>  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...
>
>
The issue is the missing (but probably implied) text,  "and valid", in RFC
4509 (where SHA-256 DS record(s) are concerned).

In the case where the SHA-256 DS record has been pre-validated, well, it's
already a no-brainer.
In the case where the SHA-256 DS record has not yet been validated, ignoring
the SHA-1 before validating the SHA-256, is either suboptimal or erroneous.

The invalidity of an individual RR in a DS RRSET (where the DS RRSET's RRSIG
*MUST* already have been validated before considering the DS RRSET) can fall
into two categories:
- obvious operator error (wrong amount of data in the DS RDATA, or otherwise
malformed DS RDATA);
- "hash mismatch" against corresponding DNSKEY(s), which COULD be a
downgrade attack.

In the case of "suspected downgrade attack", the validity could be teased
out, if there were any other DS RR's in the RRSET.
The presence of any other DS RR algorithm which validates, would be enough
to "prove" the error is operator error.
The lack of any other DS RR algorithm (beyond SHA-1 and SHA-256), means a
downgrade attack cannot be completely ruled out.
(It's still paranoid to reject a valid SHA-1 when an invalid SHA-256 exists
and no other DS RR's are present.)

The SHOULD vs MUST boils down to:
- if SHA-256 is invalid, and SHA-1 is then used, this is a "SHOULD"
behavior.
- if SHA-256 is invalid, and a present SHA-1 is never checked, this is a
"MUST" behavior.

What Paul is (I believe) indicating is that doing the latter isn't quite in
keeping with the general spirit of the RFC, or in the "be liberal in what
you accept" philosophy.

Of course, if the SHA-1 is also invalid, then it is bogus.

Brian