Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

hi Dan,

Thanks for getting this work underway.

First observation: I think a reference to RFC 6090 is warranted.

Second Observation: 80 bit crypto is on its last legs.  Do we really need to specify curves with less than 112 bit strength?

Third Observation: The security considerations section does not address the security strength of 192 or 384 bit curves.  It feels incomplete, although I guess most readers can work it out for themselves.

General observation: my experience is that specifying so many curves dilutes implementer enthusiasm.  We finally started to get some interest in ECC support for FIPS 201 when we pared the list down from six curves in three families to two prime curves (P-256 and P-384).

Specifying two alternatives for each security level feels like an implementer's nightmare.  Are Brainpool implementations general enough to handle the normal and twisted curves at a particular level?  If the implementations are agnostic, maybe that should get noted in yout insecurity considerations.

Tim

________________________________
From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Yoav Nir [ynir@checkpoint.com]
Sent: Tuesday, August 28, 2012 7:52 AM
To: Stephen Farrell
Cc: secdir@ietf.org
Subject: Re: [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote:

>
>
> On 28 Aug 2012, at 12:24, Sean Turner <turners@ieca.com> wrote:
>
>> BTW - Dan's submitted a draft about the topic we had in Vancouver. Comments are welcome.
>
> I've one: I didn't realize Dan wanted 14 code points. That seems a lot.

BTW: Johannes Merkle submitted http://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00 that requests points for the same curves for IKEv2.

I'm wondering if we really need 7 different strengths as opposed to, say, 3, and whether we need both a twisted and non-twisted variation for each. Neither document discusses the why one would prefer the twisted to the non-twisted variant, or the non-twisted to the twisted. RFC 5639 does not give such considerations either, but documents that relate to protocols should IMO.

Yoav

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview