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

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Fri, 21 Mar 2014 07:39:32 +0000

Dear all,

I've just submitted the draft below on using ECDSA with Brainpool Curves for DNSSEC. 

The rationale behind this submission is the fact that the  German electronic health insurance card (Gesundheitskarte) mandates the use of DNSSEC, while the use of Brainpool curves is recommended by the German Federal Office for Information Security (BSI). Currently, using ECC with DNSSEC is only specified for NIST Curves (RFC 6605). Hence, in order to comply with the recommendations on the one hand and with global specifications on the other hand, we wrote this draft.

Any feedback/comments/thoughts are very welcome.

Best,

Jörn

---
A new version of I-D, draft-schmidt-brainpool-dnssec-00.txt
has been successfully submitted by Joern-Marc Schmidt and posted to the IETF repository.

Name:		draft-schmidt-brainpool-dnssec
Revision:	00
Title:		ECC Brainpool Curves for DNSSEC
Document date:	2014-03-21
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-schmidt-brainpool-dnssec-00.txt
Status:         https://datatracker.ietf.org/doc/draft-schmidt-brainpool-dnssec/
Htmlized:       http://tools.ietf.org/html/draft-schmidt-brainpool-dnssec-00

Abstract:
   This document specifies the use of ECDSA with ECC Brainpool curves in
   DNS Security (DNSSEC).  It comprises curves of three different sizes.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 21 Mar 2014 11:44:54 -0400

> Any feedback/comments/thoughts are very welcome.

Is the performance of these curves any better than P256,  P384 and EC-GOST that are currently specified? 
Unless there is significant performance improvement over the Px curves this is IMHO wasted effort.

Is there a reason to believe that the curves you request are significantly stronger than the currently specified curves? 

Why are you defining 3 curves ? 
There are only about 230 code points available for algorithms, we do not want "vanity" curves specified
so unless you can JUSTIFY each one as being significantly "better" than what is currently specified 
what is the point this includes both Pxxx curves and ECC-GOST. 
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. 

Sorry for the tone of the message but you need MUCH better justification in your next version for this to be considered,
right now this looks like a pure vanity registration request. 

	Olafur 

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Mon, 24 Mar 2014 09:15:10 +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.

>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