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

From: Sean Turner <[email-masked]>
Date: Tue, 28 Aug 2012 07:24:31 -0400

BTW - Dan's submitted a draft about the topic we had in Vancouver. 
Comments are welcome.

spt

-------- Original Message --------
Subject: I-D Action: draft-harkins-brainpool-ike-groups-00.txt
Date: Wed, 08 Aug 2012 18:05:19 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Brainpool Elliptic Curves for the IKE Group 
Description Registry
	Author(s)       : Dan Harkins
	Filename        : draft-harkins-brainpool-ike-groups-00.txt
	Pages           : 26
	Date            : 2012-08-08

Abstract:
    This memo allocates code points for fourteen new elliptic curve
    domain parameter sets over finite prime fields into a registry
    established by The Internet Key Exchange (IKE).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Aug 2012 12:31:58 +0100

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.

S

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>    Title           : Brainpool Elliptic Curves for the IKE Group Description Registry
>    Author(s)       : Dan Harkins
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Aug 2012 14:52:44 +0300

> 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

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 28 Aug 2012 10:28:08 -0400

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: [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

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 28 Aug 2012 08:48:17 -0700 (PDT)

Hi Tim,

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

> Subject: Re: [secdir] I-D Action:
> draft-harkins-brainpool-ike-groups-00.txt
>
>
> 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
>

---

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

---

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.

>>> From: [email-masked] [[email-masked]] On Behalf Of
>>> Yoav
>>> Nir [[email-masked]]
> 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: Tero Kivinen <[email-masked]>
Date: Wed, 29 Aug 2012 17:28:37 +0300

> I've one: I didn't realize Dan wanted 14 code points. That seems a

BTW, I think it was bit misstated in secdir lunch that the 802.11-2012
cannot be changed anymore.

IEEE started 54-day Comment Collection perioid for IEEE
Std-802.11-2012 at 2012-07-20 and that will end 2012-09-12. I would
expect that if they are still collecting comments for the draft it can
also be still modified. Of course it might be that they are not
willing to change it anymore, but at least I already submitted
comments for requesting change (I proposed creating completely new
registry copied from IKEv1 for just this SAE use, i.e. change text on
page 1176 in subclause 11.3.4.1).

I am not sure when they are going to go through comments, and as I am
going to miss next interm IEEE meeting and next IEEE plenary meeting,
I cannot be there to explain the situation if they go through comments
there. Also if I have understood correctly this kind of change will
most likely be Technical change which require 75% approval votes from
voting members for the change to happen, so ...

----------------------------------------------------------------------
From: "Stephens, Adrian P" <[email-masked]>
To: [email-masked]
Subject: [STDS-802-11] IEEE 802.11 Comment Collection for IEEE Std
	 802.11-2012 Starts Today
Date:         Fri, 20 Jul 2012 20:59:46 +0000

IEEE 802.11(TM) Letter Ballot 802.11-2012_call_for_comments
To: IEEE 802.11 Voters,

With this email, the 802.11 Working Group is officially beginning the
comment collection period for IEEE Std-802.11-2012.

Important notes:

o             There is a 54-day comment collection period.

o             Anybody interested may provide comments.  Note that
	      access to the standard is required to provide comments.
	      A copy of the standard is on the members' area.  Those
	      who are not active can still comment provided they have
	      access to the standard from another source. 

o             Commenting is entirely optional.

o             You have to cast a vote to comment using the ePoll tool,
	      but whether you vote yes or no is entirely irrelevant.
	      Comments can only be submitted using the ePoll tool. 

The comment collection opens on: Fri Jul 20, 2012 at 23:59 Eastern
Time USA and closes 54 days later on Wed Sep 12, 2012 at 23:59 Eastern
Time USA. (Add reminder to calendar).

(The attached file contains a reminder set for 5 days before the close
of the ballot. You may find it helpful to import this into or open
this with your calendar client in order to get an automated reminder.)

Thank you for participating in Letter Ballot 802.11-2012_call_for_comments.

Bruce Kraemer, IEEE 802.11    Working Group Chair
E-mail: [email-masked]

Adrian Stephens, IEEE 802.11   Working Group Vice Chair / Balloting
Coordinator 
E-mail: [email-masked]
-- 
[email-masked]

---

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]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 Aug 2012 17:08:07 -0400

802.11-2012 is pretty much as immutable as any RFC. I believe comments
are being collected with a view towards the next big roll-up document
which would incorporate amendments to 2012 adopted in the interim and
any other changes that are thought to be good. I believe it is
expected that this next 802.11 rollup will likely be published by the
IEEE in 2015 (and if so would, of course, be 802.11-2015).

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]