Subject: RE: [Cfrg] Defining inter operable ECC keys in for IETF protocols

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Mar 2006 20:00:19 -0800

> From: Yvonne Cliff [mailto:[email-masked]] 

> Have you read the following paper?
> 
> Selecting Cryptographic Key Sizes,
> PKC 2000, Journal of Cryptology 14 (2001), 255-293 
> http://www.win.tue.nl/~klenstra/

I don't think it answers the question as directly as I would like.

Or maybe I do not like the answer and would like to see if my keys really
need to be 3072 bits.
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Whyte, William" <[email-masked]>
Date: Thu, 23 Mar 2006 03:38:44 -0500

In the X9F1 working group, we're requiring 3072-bit finite
fields for 128-bit security.

William

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 4:00 AM
> To: Yvonne Cliff
> Cc: [email-masked]
> Subject: RE: [Cfrg] Defining inter operable ECC keys in for 
> IETF protocols 
> 
>

---

From: "Whyte, William" <[email-masked]>
Date: Thu, 23 Mar 2006 03:42:13 -0500

> > What the DNSEXT working group is looking for is some guidance on how
> > to create a SHORT list of fields/curves to use by ECC in the DNS context
> > and/or wider IETF context.
> 
> Have you looked at the existing standardized NIST and SECG curves?
> 
> NIST (National Institute of Standards and Technology), US Department of 
> Commerce.  FIPS 186-2, digital signature standard (DSS).  Federal 
> Information Processing Standard (FIPS), January 2000. 
> http://www.csrc.nist.gov/publications/fips

It's common practice in some of the standards I've been working
in to reference the NIST curves, FWIW.

William

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 23 Mar 2006 11:35:44 -0500

Based on the discussion that Olafur considers unrelated to the subject - I personally recommend AGAINST using ECC in DNSEXT/DNSSEC. Because in my opinion the drawbacks outweight the benefits.
 
Thank you!
 
Regards,
Uri
<Standard Disclaimer - I speak for myself only>

________________________________

	From: Daniel Brown [mailto:[email-masked]] 
	Sent: Thursday, March 23, 2006 11:09 AM
	To: Ólafur Guðmundsson
	Cc: [email-masked]
	Subject: Re: [Cfrg] Defining inter operable ECC keys in for IETF protocols

	Dear Olafur, 
	
	1. The set of 15 different ECC domain parameters in FIPS 186-2 would be a good starting point for the short list you're seeking. 
	
	2. Formats for ECC public keys and certificates are already defined in SEC1, ANSI X9.62/63, and IETF PKIX.  (IEEE P1363, TLS and IKE also have extra formatting.) It would make sense to re-use these existing formats, especially the ASN.1 syntax, for DNSEXT.   The necessary ASN.1 syntax is simple enough to implemented with templates rather than a full ASN.1 parser, if needed.  If the DER encodings of ASN.1 in these formats is too bulky for DNSEXT, then perhaps PER encoding could be used, and failing that some custom encoding of the ASN.1 could be used. A significant advantage of the existing formats (ASN.1, TLS and IKE) is the ability to refer to ECC domain parameters by name (with an OID or integer identifier), rather than explicitly defining all the details of the elliptic curves.  This helps keeps the key sizes smaller.  The domain parameters are namable in this way are usually from a fixed set, such as the domain parameters defined in SEC2 or recommended in FIPS 186-2.   
	
	Thanks, 
	
	Dan Brown
	(905) 501-3857
	http://www.certicom.com 
	
	Ólafur Guðmundsson <[email-masked]> wrote on 03/15/2006 10:04:10 AM:
	
	> 
	> I apologize for this open ended question but the WG I co-chair DNSEXT
	> has added security extensions to the base DNS protocol (DNSSEC),
	> currently RSA/SHA1 is the main signing algorithm. DSA is also
	> defined. DSA is reaching end of life, safe RSA signatures and keys are
	> large.
	> 
	> As DNS messages are carried over UDP packets there is interest in being
	> able ECC due to the fact the keys and signatures are much smaller.
	> A proposal has been made for a ECC key format.
	> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.txt
	> 
	> Our worry is that the format proposed is open ended and people can
	> publish/use keys in fields that the rest of the world can not use due
	> to lack of support in common crypto libraries.
	> 
	> Nice feature: In the DNS world we are more interested in keeping
	> Verification time down than signing time, RSA with small exponent is quite
	> nice in this regards. I do not know if the choice of ECC variant has any
	> impact on the difference between signing and verification time.
	> If due to the shorter length of ECC key the signature verification times
	> are on-par with equivalent strength RSA key this is a non issue.
	> 
	> In some environments due to the large number of signatures that need to
	> generated in short time, hardware implementations might be required.
	> 
	> Any guidance will be greatly appreciated.
	> 
	>    Olafur 
	> 
	>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Mar 2006 11:16:31 -0800

> From: Whyte, William [mailto:[email-masked]] 

> > I would MUCH prefer ECC - but my lawyers (yuk!) are telling me that 
> > there are licensing problems, and supposed NSA contacts don't call 
> > them back.
> > 
> > Anybody knows anything useful about licensing of ECC GF(p), that he 
> > can share with me?
> 
> I asked the NSA about this last year and was told that they 
> will sublicense their ECC license only for national security 
> applications.
> 
> Certicom certainly know something about licensing of ECC.
> Why not contact them directly?

Certicom are the party alleging a broad patent claim. Some forms of ECC are
clearly out of patent, the idea was published 25 years ago. The question is
whether the Certicom patents really do cover all secure implementations or
not.

The principle interest in ECC is to address key size constraints rather than
efficiency at this point.
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Mar 2006 11:26:01 -0800

2048 bits would work, even for DKIM.

256 bytes for the key, 64 bytes for the DNSSEC signature. That leaves 190
bytes for packaging and still fit within the 500 byte DNS limit.

I would even feel relatively comfortable fitting this into DKIM even with
base64 encoded keys.

> From: Hal Finney [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 10:52 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> On 3/22/06, Hallam-Baker, Phillip <[email-masked]> wrote:
> > Would the recently proposed extended DSA with larger key sizes be a 
> > workable alternative?
> >
> > The key size is still large (does someone know how large a 
> key has to 
> > be to give 2^128 equivalent security).
> 
> The new draft specifies two subgroup size choices for 2048 bit moduli:
> 224 and 256 bits. Or you can go to 3072 bit modulus also with 
> a 256 bit subgroup. But I guess they think that a 2048 bit 
> modulus isn't too bad a match with a 256 bit subgroup, for 
> 128 bit security.
> 
> http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS
> -186-3%20_March2006.pdf
> 
> Hal
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 16:36:24 -0800

If you are going to do ECC it is much easier to do so by means of the
defined ASN.1 encodings which are almost always supported in the crypto
toolkits as a matter of course.

> From: Ólafur Guðmundsson [mailto:[email-masked]] 
> Sent: Monday, March 27, 2006 2:32 PM
> To: Daniel Brown
> Cc: [email-masked]
> At 11:09 23/03/2006, Daniel Brown wrote:
> 
> >Dear Olafur,
> >
> >1. The set of 15 different ECC domain parameters in FIPS 
> 186-2 would be 
> >a good starting point for the short list you're seeking.
> 
> Thanks, I was hoping for an even shorter list :-)
> 
> >2. Formats for ECC public keys and certificates are already 
> defined in 
> >SEC1, ANSI X9.62/63, and IETF PKIX.  (IEEE P1363, TLS and 
> IKE also have 
> >extra formatting.) It would make sense to re-use these existing 
> >formats, especially the ASN.1
> >syntax, for DNSEXT.   The necessary ASN.1 syntax 
> >is simple enough to implemented with templates rather than a 
> full ASN.1 
> >parser, if needed.  If the DER encodings of ASN.1 in these 
> formats is 
> >too bulky for DNSEXT, then perhaps PER encoding could be used, and 
> >failing that some custom encoding of the ASN.1 could be used. A 
> >significant advantage of the existing formats (ASN.1, TLS 
> and IKE) is 
> >the ability to refer to ECC domain parameters by name (with 
> an OID or 
> >integer identifier), rather than explicitly defining all the 
> details of 
> >the elliptic curves.  This helps keeps the key sizes smaller.  The 
> >domain parameters are namable in this way are usually from a 
> fixed set, 
> >such as the domain parameters defined in SEC2 or recommended in FIPS 
> >186-2.
> 
> ASN is a dirty word in the DNS community but we have used ASN 
> identifiers in some cases (CERT RR).
> The current draft
> has a compact format with lots of flexibility.
> What I expect is that ECC keys will be encoded in even more 
> compact way when defined for use in DNSSEC.
> 
>          Olafur
> 
> 
> >Thanks,
> >
> >Dan Brown
> >(905) 501-3857
> >http://www.certicom.com
> >
> > > I apologize for this open ended question but the WG I co-chair 
> > > DNSEXT has added security extensions to the base DNS protocol 
> > > (DNSSEC), currently RSA/SHA1 is the main signing 
> algorithm. DSA is 
> > > also defined. DSA is reaching end of life, safe RSA 
> signatures and 
> > > keys are large.
> > >
> > > As DNS messages are carried over UDP packets there is interest in 
> > > being able ECC due to the fact the keys and signatures 
> are much smaller.
> > > publish/use keys in fields that the rest of the world can not use 
> > > due to lack of support in common crypto libraries.
> > >
> > > to create a SHORT list of fields/curves to use by ECC in the DNS 
> > > context and/or wider IETF context.
> > >
> > > Verification time down than signing time, RSA with small 
> exponent is 
> > > quite nice in this regards. I do not know if the choice of ECC 
> > > variant has any impact on the difference between signing 
> and verification time.
> > > If due to the shorter length of ECC key the signature 
> verification 
> > > times are on-par with equivalent strength RSA key this is 
> a non issue.
> > >
> > > In some environments due to the large number of 
> signatures that need 
> > > to generated in short time, hardware implementations 
> might be required.
> > >