Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt
Paul Hoffman <paul.hoffman@vpnc.org> Wed, 05 January 2011 17:40 UTC
Return-Path: <paul.hoffman@vpnc.org>
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 6AFE83A6C69 for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 09:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.651
X-Spam-Level:
X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
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 3JIXes2uqx-k for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 09:40:53 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 828733A6AF4 for <dnsext@ietf.org>; Wed, 5 Jan 2011 09:40:53 -0800 (PST)
Received: from MacBook-08.local (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 p05HgxX8028629 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Wed, 5 Jan 2011 10:43:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D24ADA3.20305@vpnc.org>
Date: Wed, 05 Jan 2011 09:42:59 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
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]>
In-Reply-To: <a06240801c94a3ed54f9e@[10.31.200.116]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 17:40:54 -0000
On 1/5/11 7:38 AM, Edward Lewis wrote: > At 7:12 -0800 1/5/11, Paul Hoffman wrote: > >> With a non-normative slant, yes. Maybe "the DS digest should be able >> to be >> as strong as the DNSKEY signature that it covers". If someone wants to >> cover >> a strong signature with a weak hash, or vice versa, that's their choice, >> of course. > > I'd like to see this stated in DNS terms - i.e., the notion of strength > is not one of them. If this was *DNS*SEC, I would agree. However, this is more DNS*SEC*. In security, strength is particularly important. > 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. That idea (with a bit more careful wording) would work fine for current signature schemes. It might fall apart later, but it works fine for all the signature schemes under consideration. > - a validator SHOULD prefer the DS record of the same hash algorithm > over other hash algorithms for a key. 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. Ditto. > 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 is reliable as long as the hash algorithm does not have known pre-image weaknesses. None of the hash algorithms under consideration do, and in fact there are no practical pre-image attacks even for the soon-to-be-deprecated MD5. There is no future guarantee that this will be the case, of course. But, getting back to the cryptography you don't want to discuss, note that your use of "the same hash algorithm" assumes that a pre-image attack on the contents of something signed will have the same effect as a pre-image attack on the DS record. That is extremely unlikely to be true, as we have seen in recent collision attacks. Regardless, if you are unwilling to talk about strengths, using the same hash algorithm in both places is currently the best way around it. On 1/5/11 8:13 AM, Basil Dolmatov wrote: > No signatures are requiring any "strength of hash". Signers sign with some assumption of the strength of the signature against attack. One significant factor in that strength is the strength of the hash against pre-image attacks. > The implementors are the only persons who can require some strength from > some elements of security chain. True, but irrelevant. > The obvious reason for implementor to require something is to ensure > that all elements in this chain are equally reliable. Unfortunately, > "bits of strength" are not the obvious characteristics of reliability > which are good for comparison in all cases. We disagree here. I understand that, given the tight limitations of GOST, that might be true in your market. However, in a future world where there are multiple hash algorithms (thinking ahead to SHA-3), some of which will have the same effective strengths, effective strength is a reasonable measurement. > So, the demand of equality of some bits figures looks somewhat artificial. In the GOST world, yes; in the less-restricted space of open standards, no.
- [dnsext] Adopting draft: draft-hoffman-dnssec-ecd… Olafur Gudmundsson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Francis Dupont
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Alfred Hönes
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Rose, Scott W.
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Matthijs Mekking
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Olafur Gudmundsson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Olafur Gudmundsson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Olafur Gudmundsson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Edward Lewis
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Basil Dolmatov
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- [dnsext] strngths, was Re: Adopting draft:... Edward Lewis
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Chris Thompson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Basil Dolmatov
- Re: [dnsext] strngths, was Re: Adopting draft:... Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] strngths, was Re: Adopting draft:... Edward Lewis
- [dnsext] RFC 4509 was Re: Adopting draft: draft-h… Edward Lewis
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Jeffrey A. Williams
- Re: [dnsext] strngths, was Re: Adopting draft:... Paul Hoffman
- Re: [dnsext] strngths, was Re: Adopting draft:... Brian Dickson
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Francis Dupont
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Dmitry Burkov
- Re: [dnsext] strngths, was Re: Adopting draft:... Florian Weimer
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Phillip Hallam-Baker
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Florian Weimer
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Alex Bligh
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Phillip Hallam-Baker
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Paul Hoffman
- Re: [dnsext] Adopting draft: draft-hoffman-dnssec… Phillip Hallam-Baker
- Re: [dnsext] strngths, was Re: Adopting draft:... Colm MacCárthaigh