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

Brian Dickson <> Wed, 11 May 2011 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77F3BE06AE for <>; Wed, 11 May 2011 14:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5EvDHcEccN13 for <>; Wed, 11 May 2011 14:04:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2A53FE0674 for <>; Wed, 11 May 2011 14:04:06 -0700 (PDT)
Received: by fxm15 with SMTP id 15so766344fxm.31 for <>; Wed, 11 May 2011 14:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CoNWubqzWlCVc41znI3yLYrjQnLzWJOGAM6edZLkKUw=; b=tvBAX9TiXTVl3CfBEBsV8T+ImBTjEiV1mWjJZFq7BpSbgKqe7TZcH+eolkC6Z1AGgC Tn7+4Y75gyHcb8EF+hU0TuuTXmQvCdvZK01uUN9CbR9fhkwmYHND0+g7ExZnveTPaEci S0ws8lNoIXHCoY0qpcgaszYEnxkKtR+k+698A=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vdo7oa2MSwqGHJSvcm0dKa0vPvhpmceZRrF9jXkVoM9OyR+YARk04tgDGl4fzHOvTq rEESnicUSFCvjLOEmyaq1EOKgrMwSBbwjz0kck4HB57V+fp1pQPM0LmM6tcHcd2+hVK8 VXTwWpTKYgNKXBMO5cUKk4YdM9EFW1i+bJk6c=
MIME-Version: 1.0
Received: by with SMTP id j6mr1950499fax.74.1305147845288; Wed, 11 May 2011 14:04:05 -0700 (PDT)
Received: by with HTTP; Wed, 11 May 2011 14:04:05 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 11 May 2011 17:04:05 -0400
Message-ID: <>
From: Brian Dickson <>
To: Francis Dupont <>
Content-Type: multipart/alternative; boundary=002354186d84b2a2b304a30669c3
Cc: Paul Hoffman <>,
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2011 21:04:07 -0000

On Wed, May 11, 2011 at 4:22 PM, Francis Dupont

>  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"
- 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.