Re: [DNSOP] New Version Notification for draft-schmidt-brainpool-dnssec-00.txt

Schmidt, Jörn-Marc <Joern-Marc.Schmidt@secunet.com> Mon, 24 March 2014 09:15 UTC

Return-Path: <Joern-Marc.Schmidt@secunet.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26EE1A016F for <dnsop@ietfa.amsl.com>; Mon, 24 Mar 2014 02:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Level:
X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ZCjHbUDrT2 for <dnsop@ietfa.amsl.com>; Mon, 24 Mar 2014 02:15:15 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6EB1A016B for <dnsop@ietf.org>; Mon, 24 Mar 2014 02:15:15 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 6B8581A00AB; Mon, 24 Mar 2014 10:15:13 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N4dJgitydVQG; Mon, 24 Mar 2014 10:15:11 +0100 (CET)
Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id A6A0B1A00AA; Mon, 24 Mar 2014 10:15:11 +0100 (CET)
Received: from [10.53.40.205] (port=60480 helo=mail-essen-02.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WS0r1-0004we-8J; Mon, 24 Mar 2014 10:07:35 +0100
Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0174.001; Mon, 24 Mar 2014 10:15:11 +0100
From: "Schmidt, Jörn-Marc" <Joern-Marc.Schmidt@secunet.com>
To: Olafur Gudmundsson <ogud@ogud.com>
Thread-Topic: [DNSOP] New Version Notification for draft-schmidt-brainpool-dnssec-00.txt
Thread-Index: AQHPRNdRaow9KWgLMkSY4jnZinBlKprrJVqQgAB5NQCABDSTIA==
Date: Mon, 24 Mar 2014 09:15:10 +0000
Message-ID: <38634A9C401D714A92BB13BBA9CCD34F0559AA@mail-essen-01.secunet.de>
References: <20140321072940.3738.9013.idtracker@ietfa.amsl.com> <38634A9C401D714A92BB13BBA9CCD34F05516F@mail-essen-01.secunet.de> <8D85D970-10CE-4156-89C2-229836A910A3@ogud.com>
In-Reply-To: <8D85D970-10CE-4156-89C2-229836A910A3@ogud.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.208.1.85]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/k9Qbt5Aq1VrQHPiohG3U8ctnPhI
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] New Version Notification for draft-schmidt-brainpool-dnssec-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 09:15:18 -0000

Olafur,

the advantage of Brainpool curves is the fact that all  parameters are generated in a verifiably pseudo-random way. 
This topic has already been an issue in other WGs, see e.g. https://www.ietf.org/mail-archive/web/tls/current/msg10054.html 

>Why are you defining 3 curves ? 

Again, I'm looking at it from a security perspective: 256/384 bit ECC is fine for the next couple of years (NSA requires using 384 bit for "top secret" data today, see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). In my opinion, having an additional curve with a security margin ready for use is worth sacrificing one out of 230 code points.

>Defining more algorithms decreases interoperability as code bases need to pick up all algorithms. 
>While you talk about German regulations wanting some curve, that does not mean that they can mandate any domain to use it. Thus the issue of what german regulations use for health care cards is orthogonal to what is used by DNSSEC. 
>If all you want is to publish German health Insurance Card keys in DNS then ask for a "Gesundheit" record to publish the keys, and then the consumption of these records only affects the those that need to process the keys. 

True, the German regulations cannot mandate anything to this WG and it's also true that they could have a special "Gesundheit" standard/extension that has to be used within the German infrastructure.  
However, I don't think it would help the interoperability issue to add a parallel definition for signatures. Further, I believe that having a comprehensible set of curve parameters might be a welcome option for others. 

Best, Jörn