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