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

Francis Dupont <> Wed, 11 May 2011 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBFD9E0870 for <>; Wed, 11 May 2011 15:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T0VT66auB7yf for <>; Wed, 11 May 2011 15:50:31 -0700 (PDT)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by (Postfix) with ESMTP id C7381E07F0 for <>; Wed, 11 May 2011 15:50:30 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id p4BMoQZk020211; Thu, 12 May 2011 00:50:26 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Brian Dickson <>
In-reply-to: Your message of Wed, 11 May 2011 17:04:05 EDT. <>
Date: Thu, 12 May 2011 00:50:26 +0200
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 22:50:31 -0000

 In your previous mail you wrote:

   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.
=> The RFC says:

   Validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

so it doesn't say "valid" SHA-256 digests or something else.
I am sorry but there is one possible interpretation of the text,
of course we can agree the text is bad (:-). BTW I already signaled
there is no guideline for other (than SHA-1 and SHA-256) digest
algorithms so anyway a new document is needed...


PS: IMHO the idea of RFC 4509 is to replace SHA-1 by SHA-256
(and Paul shoud remark there is no well founded cryto reasons
to do that) so to provide both SHA-1 and SHA-256 is something
for the (now in the past) transitioning phase...