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

Hi Tim, Dan,

can you please move this discussion to the ipsecme mailing list 
(copied)? I believe that is a more appropriate venue to discuss IKE code 
points.

Thanks,
	Yaron

On 08/28/2012 06:48 PM, Dan Harkins wrote:
>
>    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
>>
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>