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

  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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>