[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [127.0.0.1]) 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 [192.134.4.162]) 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 [192.134.4.69]) 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)?
- [dnsext] DNSSEC, robustness, and several DS recor… Stephane Bortzmeyer
- Re: [dnsext] DNSSEC, robustness, and several DS r… Thierry Moreau
- Re: [dnsext] DNSSEC, robustness, and several DS r… Edward Lewis
- Re: [dnsext] dnsextDNSSEC, robustness, and severa… Wes Hardaker
- Re: [dnsext] DNSSEC, robustness, and several DS r… Paul Hoffman
- Re: [dnsext] DNSSEC, robustness, and several DS r… Brian Dickson
- Re: [dnsext] DNSSEC, robustness, and several DS r… W.C.A. Wijngaards
- Re: [dnsext] dnsextDNSSEC, robustness, and severa… Edward Lewis
- Re: [dnsext] DNSSEC, robustness, and several DS r… George Barwood
- Re: [dnsext] DNSSEC, robustness, and several DS r… Paul Hoffman
- Re: [dnsext] dnsextDNSSEC, robustness, and severa… Wes Hardaker
- Re: [dnsext] DNSSEC, robustness, and several DS r… Francis Dupont
- Re: [dnsext] DNSSEC, robustness, and several DS r… Brian Dickson
- Re: [dnsext] DNSSEC, robustness, and several DS r… Francis Dupont
- Re: [dnsext] DNSSEC, robustness, and several DS r… Doug Barton
- Re: [dnsext] DNSSEC, robustness, and several DS r… Mark Andrews
- Re: [dnsext] DNSSEC, robustness, and several DS r… Mark Andrews
- Re: [dnsext] DNSSEC, robustness, and several DS r… Stephan Lagerholm
- Re: [dnsext] DNSSEC, robustness, and several DS r… Doug Barton
- Re: [dnsext] DNSSEC, robustness, and several DS r… Matt McCutchen
- Re: [dnsext] DNSSEC, robustness, and several DS r… Marc Lampo
- Re: [dnsext] DNSSEC, robustness, and several DS r… Stephane Bortzmeyer
- Re: [dnsext] DNSSEC, robustness, and several DS r… Stephane Bortzmeyer
- Re: [dnsext] DNSSEC, robustness, and several DS r… W.C.A. Wijngaards
- Re: [dnsext] DNSSEC, robustness, and several DS r… Tony Finch
- Re: [dnsext] DNSSEC, robustness, and several DS r… Paul Hoffman
- Re: [dnsext] DNSSEC, robustness, and several DS r… Doug Barton
- Re: [dnsext] DNSSEC, robustness, and several DS r… Francis Dupont
- Re: [dnsext] DNSSEC, robustness, and several DS r… Doug Barton
- Re: [dnsext] DNSSEC, robustness, and several DS r… Matt McCutchen
- Re: [dnsext] DNSSEC, robustness, and several DS r… Doug Barton
- Re: [dnsext] DNSSEC, robustness, and several DS r… Francis Dupont
- Re: [dnsext] DNSSEC, robustness, and several DS r… Brian Dickson
- Re: [dnsext] DNSSEC, robustness, and several DS r… Phillip Hallam-Baker
- Re: [dnsext] DNSSEC, robustness, and several DS r… Tony Finch
- Re: [dnsext] DNSSEC, robustness, and several DS r… Phillip Hallam-Baker