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

  Hi Tim,

On Tue, August 28, 2012 7:28 am, Polk, William T. wrote:
> hi Dan,
>
> Thanks for getting this work underway.
>
> First observation: I think a reference to RFC 6090 is warranted.

  Yes, good point. I'll add a reference to it at the start of section 2 where
the equation for the curves is noted.

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

  There is the notion that "if it's worth protecting, it's worth protecting
properly" and I'm not sure of the current usefulness of 80-bit crypto but
this is more for completeness. The Brainpool defined them and I'm just
asking for a magic numbers to be assigned to all the defined curves.

  That also is the the answer to the "14 code points, oh my!" comments.
Note that we still have over 32,000 code points available so we're talking
about taking 4/100th of 1%.

> 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.

  I refer the reader to RFC 5639 which mentions the security considerations
of the curves. If you like I can also mention something about how the best
known attacks run on the order of the square root of the order. Would that
be satisfactory?

> 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).

  That is a very good observation. I guess we should talk to the Brainpool.
Their consortium seems to have some large and important companies in
it. The concern is that one of the members would promote the use of a
particular curve in some operational or regulatory fashion and it's
important that the users of the IKEv1 registry be able to work anywhere.

> 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.

  You're right, it is a nightmare! As it turns out quite a few of my test
vectors are wrong. I think implementations will be agnostic and I will
mention agnosticism.

  thanks for your comments!

  Dan.

> 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
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>