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

Hi Dan,

See inline.

spt

On 10/12/12 2:32 AM, Dan Harkins wrote:
>
>    Hi Sean,
>
> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
>> 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?
>
>    Yes, that's correct because the code points would just be there and
> the other protocols that use this registry would just blissfully start
> to refer to them. This whole problem started because some people
> decided that it was some sort of process issue to update this registry
> (Note: it's not).
>
>    Again, this could've been just like RFC 5114-- no fuss, no mess,
> no hullaballo. If precedence has been followed, none of this nonsense
> would've happened.
>
>    These notes and pointers that people may or may not pay attention
> to are just meta problems and they're all completely manufactured.
> They will all just go away if we just follow the path that RFC 5114 blazed.

Okay so I get it now.  If a brainpool curves for IKEv1 was published the 
IEEE wouldn't have made the request.

>> 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 don't understand your proposal. What is "the combined issue"? If
> the registry is not updated now and, instead is updated at a later date,
> then what is being done now?

Sorry by combined issue I'm referring to waiting on figuring out whether 
the registry values will be included without the not for IKEv1 note.

>    I have a draft that will need to get updated and the clock is ticking on
> that (cut-off date is 22 Oct). I need to know what you want my draft
> to say.

I should have an answer by Thursday.

>> 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.
>
>    Can you ask the IESG to just do what it has done in the past? That is,
> just update the registry to include code points for new curves without
> any bizarre notes or pointers? No fuss, no mess, just a few new rows
> in a table.
>
>    The worst that could happen if the IESG agrees to do that is that someone
> somewhere might use a brainpool curve with IKEv1. The odds are slim,
> but they're not zero. And if that happens then so what? Really. So what?

The RFC 5114 example wasn't published to address another SDO request for 
a code point so I don't think it's the same situation.

spt

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