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

[Sean Turner <[e-mail]>]

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