Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

Chris Thompson <cet1@cam.ac.uk> Wed, 05 January 2011 18:37 UTC

Return-Path: <cet1@hermes.cam.ac.uk>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDB13A6C9F for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 10:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1jg4gsagtnP for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 10:37:38 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 13A9E3A6C69 for <dnsext@ietf.org>; Wed, 5 Jan 2011 10:37:37 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53268) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1PaYGs-0004fI-pc (Exim 4.72) (return-path <cet1@hermes.cam.ac.uk>); Wed, 05 Jan 2011 18:39:42 +0000
Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1PaYGr-0006N6-Vu (Exim 4.67) (return-path <cet1@hermes.cam.ac.uk>); Wed, 05 Jan 2011 18:39:41 +0000
Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 05 Jan 2011 18:39:41 +0000
Date: Wed, 05 Jan 2011 18:39:41 +0000
From: Chris Thompson <cet1@cam.ac.uk>
To: Edward Lewis <Ed.Lewis@neustar.biz>
Message-ID: <Prayer.1.3.3.1101051839410.18449@hermes-2.csi.cam.ac.uk>
In-Reply-To: <a06240801c94a3ed54f9e@[10.31.200.116]>
References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <a06240801c94a3ed54f9e@[10.31.200.116]>
X-Mailer: Prayer v1.3.3
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-1"
Sender: Chris Thompson <cet1@hermes.cam.ac.uk>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsext@ietf.org
Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cet1@cam.ac.uk
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 05 Jan 2011 18:37:39 -0000

On Jan 5 2011, Edward Lewis wrote:

>I'd like to see this stated in DNS terms - i.e., the notion of 
>strength is not one of them.
>
>I would suggest that
>
>  - the authoritative set of the DS record SHOULD include a DS RR for 
>each key that is of the same hash algorithm as is used in the key and 
>MAY have other hashes (and MAY even have only other hashes[1])
>
>[1] The parenthetical comment is redundant, put it there for emphasis.
>
>  - a validator SHOULD prefer the DS record of the same hash algorithm 
>over other hash algorithms for a key. 

You mean that a validator should prefer a digest type 1 (SHA-1) DS over
a type 2 (SHA-256) DS if the key to be validated uses algorithm RSASHA1?
This directly contradicts the SHOULD in RFC 4509 section 3, and also
doesn't seem too sensible to me.

>                                       Prefer means that it SHOULD be 
>the first tried and if it fails, the validator MAY declare failure 
>without examining the other applicable hash algorithms.  A validator 
>MUST NOT require that there be a hash of the same algorithm present, 
>with require meaning - if such a hash is absent, failure is not 
>automatic.
>
>You may note that I spec "the same hash algorithm" because I don't 
>know of any way to say if one hash algorithm is stronger than the 
>next.  I.e., bit length might be an indicator but I bet it also isn't 
>reliable.

It's perfectly possible for an implementor, or an operator, to have
opinions about this, though.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.