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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 28 Aug 2012 19:05:45 +0300

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: [email-masked] [[email-masked]] On Behalf Of Yoav
>> Nir [[email-masked]]
>> Sent: Tuesday, August 28, 2012 7:52 AM
>> To: Stephen Farrell
>> Cc: [email-masked]
>> 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 <[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> _______________________________________________
>> secdir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>
>
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 28 Aug 2012 10:49:03 -0700 (PDT)

Hi Yaron,

> (copied)? I believe that is a more appropriate venue to discuss IKE code

  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.

> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Aug 2012 11:18:27 -0700

> draft adds to the registry, which sort of makes this not an IKE

I was with you until that last phrase. It most certainly is an IKEv1 code point discussion.

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

What I want is for you to be less snarky in your communication, both on-list and in the Internet-Drafts you write. I would also want you to be clearer in your drafts when you are talking about IKEv1 or IKEv2: in this draft, even in the filename, you kind of hid that.

Whether or not you want to do those, I want the ADs to decide whether it is appropriate to do more work on IKEv1, such as adding these curves to the IKEv1 registries. If they think the work is appropriate, they can also say where it should be done.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 28 Aug 2012 11:54:09 -0700 (PDT)

> I was with you until that last phrase. It most certainly is an IKEv1 code

  If you insist that the registry say "not for IKEv1" then the
code points are not for IKEv1 and any discussion about code points
that are not for IKEv1 is not an IKEv1 code point discussion.

> What I want is for you to be less snarky in your communication, both
> on-list and in the Internet-Drafts you write. I would also want you to be
> clearer in your drafts when you are talking about IKEv1 or IKEv2: in this
> draft, even in the filename, you kind of hid that.

  Please rephrase your wants into specific comments on the draft that
I can then accept, counter, or reject. And please do not send them to
the IPsecME list because, as you said, this "is *not* an IPsecME WG
issue" (emphasis yours).

> Whether or not you want to do those, I want the ADs to decide whether it
> is appropriate to do more work on IKEv1, such as adding these curves to
> the IKEv1 registries. If they think the work is appropriate, they can also
> say where it should be done.

  They already did; you were there.

  Dan.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Aug 2012 08:57:29 -0400

Dan,

My recollection is that the agreement at the SECDIR meeting was that a 
waring of the form "not for use with IKEv1" was part pf the deal. I 
still believe this is a very questionable way to accommodate the IEEE's 
unwillingness to maintain their own registry, and their slow doc rev 
cycle time that is causing us to do a silly (at best) thing.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 29 Aug 2012 17:45:21 +0300

> that are not for IKEv1 is not an IKEv1 code point discussion.

That registry is for IKEv1. Meaning ANY changes to those registries
are still IKEv1 issues. Regardless whether we say that those points
are not for IKEv1 use.

Are you saying that if I want to add 2000 new cipher suites to TLS
registry (from the Specification Required space) and say that they are
not for TLS use, I do not need to ask anything from the TLS working
group?

So I myself at least do consider this to be also IKE issue even when
the groups are not for IKEv1 use, just because it changes IKEv1
registry. 

> the IPsecME list because, as you said, this "is *not* an IPsecME WG

Remove the completely stupid "5. Insecurity Considerations" containing
your own biased opionions of the reality.

Add proper note why these things are to be added at all.

You say in the section 1 that "Other pprotocols, ...", but do not
point out any other than IEEE802.11, is there some other protocols
referencing this registry than the IEEE802.11? Also it would be better
to say that in the IEEE 802.11 only the SAE uses this registry. Also
how widely supported SAE is? I have not seen it in any of the user
interfaces for wlan systems I have configured at?

Also the point that these groups are not for IKE is bit misleading
when the title says IKE, and abstract talks about adding groups to
"registry established by Teh Internet Key Exchange (IKE)", but does
not point out that it is not for that protocol at all...

>   They already did; you were there.

I was there too, but I think I missed it too.

Can you tell me what did they decide? Is it approriate to do any more
work on IKEv1? And if so where should it be done?
-- 
[email-masked]