[IPsec] brainpool summary, suggested way ahead, and comments on draft

[Sean Turner <[e-mail]>]

I'd like to discuss the IEEE's request for brainpool code points 
additions in the Group Description registry 
(https://www.iana.org/assignments/ipsec-registry) on this mailing list. 
  I realize it's not in scope of the WG, but all the right people are 
here so I'd like to ask for the wg chair's and member's indulgence on 
this matter.

Here's the summary of events as I remember them:

Stephen and I got an informal liaison from IEEE 802.11 requesting code 
point assignments in the Group Description section of 
https://www.iana.org/assignments/ipsec-registry.  Since then we've 
received the official liaison.  And we figured inviting Dorthy along to 
secir would cut down on some email.

My initial thought was that adding anything to this registry was an 
update to IKEv1 and that was pretty much a no-go because IKEv1 is 
obsolete.  But, the registry is RFC required so that's not strictly 
true.  That is, other code points have been assigned after IKEv1 was 
obsoleted.

The other thing that came to light was that the code points were in fact 
not going to be used by IKEv1 they were being used by another protocol, 
the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol.

I think it's fair to say that at the meeting most people weren't 
thrilled that IEEE plans to reuse the registry.  We discussed setting up 
a new registry or pointing from the existing registry to a new registry, 
but the IEEE folks didn't like that because their spec is apparently not 
up for change until 2015 (Tero has submitted comments on this topic in 
IEEE).

What I thought we came to was that Dan would publish a draft that 
requested the points and that the "notes" column would contain "not for 
IKEv1" - and then we'd talk about it.  Dan submitted the draft 
requesting 14 code points with "not for IKEv1" in the notes column for 
each code point.  I forwarded it to secdir and here we are.

^
| summary

| way ahead discussion
v

 From the discussion following publication, it's still clear the dual 
use of the registry is still unloved.  I share that view.  I think it 
comes down to this:

- On the one hand, putting "not for IKEv1" in the notes column assumes 
that whoever consults the registry will make note of the note and not 
implement (or ask for them to be implemented) the code points in IKEv1. 
  Concerns have been expressed that the note won't be enough to stop 
people asking for IKEv1 products to support these new code points - not 
thrilled about this prospect.

- On the other hand, getting the IEEE spec to point to a new registry is 
(or might be) a no-go because of their publishing cycle.  Assuming the 
IEEE spec can't be changed and we don't assign the code points, I'm sure 
some kind of inter-SDO struggle/spat will occur - not thrilled about 
this this prospect either.

In this unfortunate situation, I'd like everyone to consider the (third 
surgically attached) hand that shares the burden: reserve the code 
points for 802.11 SAE in the Group Description registry, be very 
explicit about it in the draft/regstry, and then point from the Group 
Description registry to another registry (thanks to whoever suggested 
this at the secdir lunch we probably should have explored this more). 
The burden is then shared by the IETF assigning code points for 
something some despise/dislike and the IEEE implementers following an 
additional link from the registry they've already got to consult  (they 
have to follow the link because the registry values aren't copied to 
their spec).  The registry entries would appear as follows (well Value, 
Group, Reference, and Notes would normally appear on one line but it 
wraps in email and I thought this would be easier to follow):

Value
-----
27-y

Group
-----------------------
Reserved for 802.11 SAE

Description
------------------
This specification

Notes
-----------------------------------------
Not for use with IKEv1 - see xyz registry

and then link 27-y to the curve names in the xyz registry (more on the 
number of code points at the end):

Value Group                          Reference
----- ------------------------------ ------------------
27    X-bit Brainpool: brainpoolPXr1 This specification
...   ...                            ....


Thoughts about this?


| comments on draft
v

I'd like to make to the draft clearer about what's going on:

#1) Retitle:

OLD:

  Brainpool Elliptic Curves for the IKE Group Description Registry

NEW:

  Brainpool Elliptic Curves for 802.11 SAE in the
          IKE Group Description Registry

#2) tweak abstract:

OLD:

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

NEW (where X is TBD at this point):

  This memo allocates code points for X new elliptic
  curve domain parameter sets over finite prime fields
  into a registry established by The Internet Key
  Exchange (IKE).  These values are used by the IEEE
  802.11 SAE (Simultaneous Authentication
  of Equals) protocol.  The values found in this
  document are not for use in IKEv1.

#3) tweak intro:

OLD:

  IANA maintains a registry for [RFC2409] to map
  complete domain parameter sets to numbers.  Other
  protocols, for example [IEEE802.11], refer to this
  registry for its convenience.  Therefore, this memo
  instructs IANA to allocate new code points for the
  Brainpool curves defined in [RFC5639] to the registry
  established by [RFC2409].

NEW:

  [RFC2409] defined the Group Description registry that
  other protocols, for example [IEEE802.11], refer to for
  convenience. Non-IKE protocols referring to the registry
  is not ideal but also not a problem until the non-IKE
  protocol(s) want values added to the registry and these
  values are not for use by IKE.  This is the case with the
  values in this document; they are not for use with IKEv1.
  The values in this document are for the Brainpool curves
  defined in [RFC5639] use with 802.11 SAE and the
  documents only purpose is to instruct IANA to allocate
  new code points.

#4) Pick fewer curves.  Not sure which ones but if we end up doing 
brainpool in TLS I'd like to see us pick the same ones.  Not sure which 
ones those will be.  I'm thinking like 3 - probably lining up with the 3 
ECP groups.

#5) Once we've settled on the format for the registry put it exactly as 
agreed in the IANA section.

spt