[dnsext] DNSSEC, robustness, and several DS records

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 11 May 2011 08:02 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B9CE1E0782 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 01:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6KSAAeTZFwDJ for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 01:02:01 -0700 (PDT)
Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D7E06C1 for <dnsext@ietf.org>; Wed, 11 May 2011 01:02:00 -0700 (PDT)
Received: from mx2.nic.fr (localhost []) by mx2.nic.fr (Postfix) with SMTP id 8BA741C0091 for <dnsext@ietf.org>; Wed, 11 May 2011 10:01:59 +0200 (CEST)
Received: from relay1.nic.fr (relay1.nic.fr []) by mx2.nic.fr (Postfix) with ESMTP id 87C751C001D for <dnsext@ietf.org>; Wed, 11 May 2011 10:01:59 +0200 (CEST)
Received: from bortzmeyer.nic.fr (batilda.nic.fr []) by relay1.nic.fr (Postfix) with ESMTP id 863A056812B for <dnsext@ietf.org>; Wed, 11 May 2011 10:01:59 +0200 (CEST)
Date: Wed, 11 May 2011 10:01:59 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dnsext@ietf.org
Message-ID: <20110511080159.GA13132@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: Debian GNU/Linux 6.0.1
X-Kernel: Linux 2.6.32-5-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [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 08:02:01 -0000

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.

I question this rule: SHA-1 (as it is used for DNSSEC) is not broken
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. Isn't it a case of excess security, which will turn people away
from DNSSEC (too much risk of breakage)?