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

  Hi Yaron,

On Tue, August 28, 2012 9:05 am, Yaron Sheffer wrote:
> 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.

  When the IEEE liaison brought up this issue, your co-chairman
said, "Yaron and I should "not* be part of this discussion because
the issue is *not* an IPsecME WG issue. It is not in our charter
to make additions to the obsoleted-but-still-widely-used IKEv1
protocol." He is also the one who insisted on the note that the
draft adds to the registry, which sort of makes this not an IKE
code point discussion.

  If this is an IKE discussion, I'd be happy to discuss this on the
ipsecme list and I'd be, therefore, happy to remove the note and the
corresponding "Insecurity Considerations" from the draft.

  But maybe you guys should go off and decide what you want.

  Dan.

>
> 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
>>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>