Dan,
Thanks for the backfill (ack that's it's not just for SAE).
Question: If Johannes's draft had gone through for IKEv1 you wouldn't
have needed to make the request for the code points?
Because a clock is apparently ticking on the request I think we need to
address the request in front of us not the combined issue. If at a
later date, the registry is updated to add Brainpool curves then the
"Group Description" rows for those can be updated.
I'm going to run my proposal and Michael's by the IESG on an informal
telechat to see which one's got the best chance of getting through the
process to resolve the IEEE's request.
spt
On 9/21/12 4:42 PM, Dan Harkins wrote:
Hi Sean,
There's some missing (pre)history and context. Let me try to fill it in.
Back in early July, Johannes Merkle sent a note to the list saying he
wanted to use the elliptic curves proposed by the ECC Brainpool with
IKE and IPsec. He asked a series of questions, one of which was:
"Should we include IKEv1 in the specs as well?"
I voiced support but there was some opposition along the lines of:
* we cannot update the IANA registry of an obsoleted protocol.
* it is not appropriate for a protocol other than RFC 2409 to use
the IANA registry created by RFC 2409.
Both of these are wrong. RFC 5114 updated this very same registry
after RFC 2409 was obsoleted and there was no hullabaloo over
that action. And RFC 5931 (EAP-pwd) uses that registry and it
got approved for publication long after RFC 2409 was obsoleted,
again without any hullabaloo.
There is no valid process reason to not just let Johannes's draft
update the IKEv1 registry while it's updating the IKEv2 registry
(just like RFC 5114 did) and there is precedence which we could
just follow to avoid all this mess.
In spite of that. it was decided to not update the IKEv1 registry
with the Brainpool curves. When IEEE got wind of this, they sent
a request, via the IEEE-to-IETF liaison, to please reconsider since
they have more than 1 protocol used in 802.11 that reference
that registry (i.e. it's not just SAE). The concern was that there
may be administrative or regulatory reasons for some entity to
desire or require using the Brainpool curves and 802.11 wants
to ensure that it can be used everywhere, or at least not
prohibited from being used because of a misguided effort by
the IETF to kill off use of a different protocol.
It is the nature of this reconsideration-- forbid IKEv1 from using
the updated registry or create some new registry and forbid IKEv1
from using it-- that is causing this whole kerfuffle. IEEE 802.11's
long (from our standpoint) revision schedule is not the cause of
the problem here.
The reason to not just update the IKEv1 registry with the Brainpool
curves and to prohibit it's use with these curves is, apparently,
the concern that someone somewhere might actually use them with
IKEv1. It is not a certainty that that will happen and, furthermore, it
is not apparent to me what calamity will befall us all if somebody did.
So my preference would be to follow existing precedence and let
Johannes's draft update both registries without any ridiculous notes.
If that were to happen we could let my draft die a natural death and
end the kerfuffle. If that just cannot be then I'll update my draft to
reflect your proposed edits, with the modification that this is not just
for SAE and not just for 802.11. Also, if you want to limit the number
of curves (item #4) you should coordinate with Johannes on his draft
for the IKEv2 registry as well as his TLS draft.
regards,
Dan.
On Fri, September 21, 2012 7:19 am, Sean Turner wrote:
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
