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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 11 May 2011 17:52 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 4C336E0871 for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 10:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level:
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 sFZwrHIE3yXh for <dnsext@ietfa.amsl.com>; Wed, 11 May 2011 10:52:14 -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 44608E0876 for <dnsext@ietf.org>; Wed, 11 May 2011 10:52:14 -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 p4BHqAAM023840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 10:52:11 -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>
X-Priority: 3
In-Reply-To: <C7A4C74DA86C4A5A977C0902C1D2795E@local>
Date: Wed, 11 May 2011 10:52:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <41FE5ADA-EDF1-45B2-8149-9CD0DA1E6929@vpnc.org>
References: <20110511080159.GA13132@nic.fr> <63381BB3-7552-4721-B334-CFE292AA9465@vpnc.org> <C7A4C74DA86C4A5A977C0902C1D2795E@local>
To: George Barwood <george.barwood@blueyonder.co.uk>
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 17:52:15 -0000

On May 11, 2011, at 10:28 AM, George Barwood wrote:

>>  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.
> 
> The problem is that we don't know if such attacks exist, and more practically
> it's hard to update software.

The first phrase is not true, and the second is not terribly relevant.

- There have been no known preimage attacks on SHA-1. When there is, the world will hear about it. And, before you say "but we might not hear about it", please understand that you can say exactly the same thing about RSA signatures themselves. Either you live with "the crypto experts will tell us when some component is unsafe", or you just freeze and don't do anything.

- If there is a preimage attack on SHA-1, or a much better attack on RSA, or...or...or..., then the software will have to be updated. It will will be hard to do so in some cases, but not in others.

> So it seems better to plan for the worst.

That logic leads to banning SHA-1 outright immediately. And yet the WG (correctly, IMNSHO) decided not to.

> Besides, implementations may want to use dual algorithms, for example
> elliptic curve plus RSA with a moderate size key, on the basis that it's
> unlikely that anyone would be able to break both.

To date, the tools used to weaken hashes are not the same as those used to weaken signature algorithms, so this sentence doesn't make sense in the current world.

> I really doubt having resolvers trying to fix up data errors is the way forward.

Fully agree.

--Paul Hoffman