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.