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

Florian Weimer <fweimer@bfk.de> Fri, 07 January 2011 15:13 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190233A68CB; Fri, 7 Jan 2011 07:13:30 -0800 (PST)
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 5C3383A68EC for <dnsext@core3.amsl.com>; Fri, 7 Jan 2011 07:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 Oxr4ON6--lH5 for <dnsext@core3.amsl.com>; Fri, 7 Jan 2011 07:13:28 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 52BF93A68EA for <dnsext@ietf.org>; Fri, 7 Jan 2011 07:13:26 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PbE2D-0000tH-Qx; Fri, 07 Jan 2011 15:15:27 +0000
Received: by bfk.de with local id 1PbE1l-0003Qk-SO; Fri, 07 Jan 2011 15:14:53 +0000
To: Phillip Hallam-Baker <hallam@gmail.com>
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> <Prayer.1.3.3.1101051839410.18449@hermes-2.csi.cam.ac.uk> <AANLkTimnz9CBDbjXc0V2=zdM6PZnSs4_+ZaEL8CCVbXk@mail.gmail.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Fri, 07 Jan 2011 15:14:53 +0000
In-Reply-To: <AANLkTimnz9CBDbjXc0V2=zdM6PZnSs4_+ZaEL8CCVbXk@mail.gmail.com> (Phillip Hallam-Baker's message of "Fri\, 7 Jan 2011 09\:32\:56 -0500")
Message-ID: <821v4oeoeq.fsf@mid.bfk.de>
MIME-Version: 1.0
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, 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
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

* Phillip Hallam-Baker:

> Work factor using known best attack is much better defined.

Nope, because attacks tend to be theoretical, and it is hard to tell
if the attacks could actually implemented as described in the
technical reports, given sufficient resources.  Things like
communication overhead in a parallel implementation are difficult to
estimate and often not taken into account.  Even if this is resolved
in some way (but it won't ever happen, I'm pretty sure), you have to
deal with the question of trade-offs: how do you fold sizes and
bandwidths of several types of storage, processing speeds and
communication costs into a single number?

If there are working attacks which you can run on real hardware, it
makes sense to speak of work factors.  But then, you don't want to use
the algorithms anymore, so this isn't an interesting case, either.

> But all this is really outside the parameters of what DNSEXT should
> have to concern itself with.

I agree.  If there's a solution for this issue (due to very
significant advances in cryptography, which are rather unlikely, given
past performance), then the DNSSEC standards can use that knowledge.
Right now, there is no such thing, at least in the public literature.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext