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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 11 May 2011 14:27 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A019E0728 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level:
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+ugJBS8bd3X for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 07:27:52 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 611F6E0685 for <dnsext@ietf.org>; Wed, 11 May 2011 07:27:52 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BERoOU013212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 07:27:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20110511080159.GA13132@nic.fr>
Date: Wed, 11 May 2011 07:27:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org>
References: <20110511080159.GA13132@nic.fr>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.1084)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2011 14:27:56 -0000

On May 11, 2011, at 1:01 AM, Stephane Bortzmeyer wrote:

> A recent incident lead me to re-study the question of "what a
> validating resolver must/should do when there are several DS and some
> are invalid in some way?" AFAIK (I would be glad to be corrected
> here), the best common practice is to be lax ("DNSSEC is hard enough,
> accept any DS"), following RFC 4035, section 2.4 and 5.3.1.
> 
> But it seems there is an "exception". RFC 4509, section 3, says that
> DS hashed with SHA-1 must be ignored when there is a DS for the same
> key hashed with SHA-2. This is to avoid downgrade attacks.
> 
> In the incident I was talking about, there were two DS for the same
> KSK key, one hashed with SHA-1 and one with SHA-256 and the second one
> was invalid, because of a bug (wrong Algorithm field). As a result,
> both BIND and Unbound, following RFC 4509, returned a SERVFAIL, while
> there was another and perfectly valid DS record.

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 question this rule: SHA-1 (as it is used for DNSSEC) is not broken

Correct.

> and the risk of downgrade attacks is ridiculous when you compare, both
> to the other attacks on DNSSEC, and to the risk of creating an
> error.

Correct. 

> Isn't it a case of excess security, which will turn people away
> from DNSSEC (too much risk of breakage)?

No, because it adds no security, so it cannot be "excess security". It feels more like a case of a spec with a SHOULD that does not include guidance on when to consider an exception. If people here want to revise RFC 4509 to reflect security practices that balance risk from known attacks against cost to attackers, I would propose changing:

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

to:

   If there is a known preimage attack on SHA-1 that reduces its
   effective strength to less than 128 bits,
   validator implementations SHOULD ignore DS RRs containing SHA-1
   digests if DS RRs with SHA-256 digests are present in the DS RRset.

--Paul Hoffman