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

From: Sean Turner <[email-masked]>
Date: Thu, 11 Oct 2012 18:51:52 -0500

On 9/21/12 12:39 PM, Michael Richardson wrote:
>
>>>>>> "Sean" == Sean Turner <[email-masked]> writes:
>      Sean> that requested the points and that the "notes" column would
>      Sean> contain "not for IKEv1" - and then we'd talk about it.  Dan
>
> ...
>
>      Sean> In this unfortunate situation, I'd like everyone to consider
>      Sean> the (third surgically attached) hand that shares the burden:
>      Sean> reserve the code points for 802.11 SAE in the Group
>      Sean> Description registry, be very explicit about it in the
>
> As I was reading up just before this, my thought was to write, rather
> than "not for IKEv1", instead write:
> 	"only for 802.11 SAE"
>
> but it would actually say what they were.
>
>      Sean> more). The burden is then shared by the IETF assigning code
>      Sean> points for something some despise/dislike and the IEEE
>      Sean> implementers following an additional link from the registry
>      Sean> they've already got to consult (they have to follow the link
>      Sean> because the registry values aren't copied to their spec).  The
>
> I understand that you are hacking on the dumb customer reading registry
> is also too dumb to follow the breadcrumbs over to IEEE in order to find
> out what the groups are, in order to properly demand things.
>
> <TCPDUMP HAT ON>
> I don't like this.
> I want to know what the code point is for.  tcpdump is not implementing
> the protocol, just decoding it.   I don't know if IEEE 802.11 will let
> me see the assignments without jumping through hoops, of it they
> will get mad if someone who has access to documents, submits a patch.
> </TCPDUMP HAT OFF>
>
> I claim that customers are actually too dumb to read the IANA registry
> anyway, at most they grep rfc-index.txt for "IPSEC" and list that.  So
> actually it doesn't matter what we say in the IANA registry, as long
> as implementers get it, it's okay.
>
> if: "Reserved for 802.11 SAE Brainpool Group 14"
> will fit, I say go for that.  It means that tcpdump will print something
> like that out if it sees things (and if this is used in the parent SA,
> it will be visible).

Michael,

I can see your point.  I can see that the additional layer of 
redirection I added could be considered useless.  From a procedural 
point of view though, I think we should discourage dual use of registries.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Oct 2012 19:47:20 -0500

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 11 Oct 2012 23:32:13 -0700 (PDT)

Hi Sean,

> 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.

> "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?

  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.

> 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?

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 11 Oct 2012 23:32:15 -0700 (PDT)

Hi Sean,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Oct 2012 14:56:34 +0300

> no hullaballo. If precedence has been followed, none of this nonsense

It is even easier to just drop the whole issue, and leave brainpool
curves completely out, no fuss, no mess, no hullaballo. There has been
precedence for that too, we have had proposals for IKEv1 which have
been dropped and never gone forward or never even implemented (for
example my revised hash format, notify message payload format etc).

All additions / modifications etc do require some considerations
before they are accepted. Things in the documents are not same (for
example number of groups, the fact that 5114 already defines ECP
groups for IKEv1 etc), time is not same (IKEv1 has been obsoleted
almost 5 more years after the 5114 was published) etc. 

Also we do make mistakes, and we are supposed to be able to fix them.
If we are never allowed doing anything else than what was done before,
there is no way we can fix mistakes afterwards as this is how it was
done once before, this is how it must be done forever in the future
too. 

>   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.

What is this draft you are refering here? Some IETF draft or some IEEE
document? 

> any bizarre notes or pointers? No fuss, no mess, just a few new rows

How about asking instead that do nothing, do not update the registry,
and if IEEE has problems with that they can fix their document to
refer to their own registries, or ask IANA to allocate new registry
which they can manage and use that...

I think the compromise Sean is proposing (i.e. add them as reserved
values to the IKEv1 registry, add note to point them to new registry
which defines them and create that new registry containing them) is
good proposal, and I do not see why you are so much against it? It
will allow using the groups in the IEEE, it does add one extra
redirection, but only implementors should ever need that thus they
should be able to follow pointers, it makes it clear for IKEv1
implementors that these numbers are not for IKEv1, which will make
some people (including me) happy. 
-- 
[email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 12 Oct 2012 09:43:53 -0700 (PDT)

> example my revised hash format, notify message payload format etc).

  You're conflating two different issues. This has nothing to do with
the protocol.

> almost 5 more years after the 5114 was published) etc.

  But this is not a modification. This is an RFC required change to a
registry. We're talking about making an RFC to update the registry.

> What is this draft you are refering here? Some IETF draft or some IEEE

  The draft that is referred to in the subject of this email. The draft that
is going to end up having all these nonsensical notes and pointers and
crap in it. That draft.

> which they can manage and use that...

  We've already been through that. It's not a productive use of time
to bring this up again.

> some people (including me) happy.

  It's not so much that I'm against this, it's that there is this huge
discussion about notes and pointers and whether people will respect
the notes and whether they can follow the pointers and making sure
there is a sufficiently large enough firewall to keep IKEv1 implementers
out while allowing others in... All of this is manufactured. These are
all solutions to problems that we are imposing on ourselves. If we
just decide not to impose those problems on ourselves then there
is no need for these convoluted and ridiculous "solutions".

  H.L. Mencken once said that "puritanism is the haunting fear that
someone somewhere might be having a good time." I think you have
a haunting fear that someone somewhere might actually be working
on IKEv1. And because of this haunting fear of yours you have succeeded
in creating the problems and issues that require this convoluted and
bizarre "way ahead" that we are all discussing.

  All of these problems just go away if we follow process and precedence.
If you will just stop being afraid that someone somewhere might do
something you don't like we can get this nonsense behind us.

  We're discussing a way ahead in this thread. I think that way is clear:
let's just let Johannes follow the path that draft-lepinski-dh-groups
did. A short, simple draft to update both registries without any cruft
and notes and pointers and nonsense. It's easy, it's problem-free!

  Dan.

---

From: Sean Turner <[email-masked]>
Date: Mon, 15 Oct 2012 20:00:52 -0400

Hi Dan,

See inline.

spt

> 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.

> 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.

> that (cut-off date is 22 Oct). I need to know what you want my draft

I should have an answer by Thursday.

> 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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 15 Oct 2012 19:54:03 -0700 (PDT)

Hi Sean,

> a code point so I don't think it's the same situation.

  That's certainly a distinction but I don't see how that matters. You
could also
note that RFC 5114 added MODP groups as well as ECP groups. Also a
distinction that really doesn't matter.

  Again, the SDO request is a _by-product_ of the opposition to just letting
Johannes' draft update the registry. It is this same opposition that is
creating
these problems about notes and pointers and the concern over whether they
will have the desired effect and what we should do to ensure they do. If this
opposition had not materialized there never would've been another SDO
request.

  It is the same situation, indulge me here a bit:

  What we had was another organization (NIST) came up with some new DH
groups and there was a proposal to add them to both IKEv1 and IKEv2
registries. And now, quite similarly, there's another organization (the ECC
Brainpool) that came up with some new DH groups and there was a proposal
to add them to both IKEv1 and IKEv2 registries.

  When the proposal was made to add the NIST groups to the IKEv1
registry there was no hullabaloo over updating a deprecated protocol's
registry and there was no concern that someone somewhere might use
the NIST groups with IKEv1.

  But when Johannes made his proposal to add the ECC Brainpool curves
to the IKEv1 registry there was all of a sudden a hullabaloo and much
concern that someone somewhere might use the ECC Brainpool groups
with IKEv1.

  So my request to you is to ask that the IESG consider what the process
defined for updating this registry is (it's RFC required) and to note that
there is precedence to update the registry of this deprecated protocol.
So please ask the IESG to just approve a draft (either Johannes' or mine)
for publication as an RFC to update this registry in the same manner that
RFC 5114 updated it (i.e. no notes, no pointers, no nonsense).

   Then there'd be no need for the IESG to have a discussion about the
(de)merits of notes and pointers in registries and how best to ensure that
no one nowhere ever even thinks about using an ECC Brainpool curve in
IKEv1 and that certainly sounds like a better use of everyone's time.

  regards,

  Dan.

---

From: Sean Turner <[email-masked]>
Date: Thu, 18 Oct 2012 10:58:04 -0400

Dan,

There's not need to ask the IESG about the process to update the 
registry in question it's clear: RFC required.  You can get an RFC 
through a WG, through an AD, or through the ISE.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 18 Oct 2012 12:12:35 -0400

Dan,

After talking it over the preferred* approach to answer the 802.11 
request is to include them in the IKEv1 registry (as suggested by 
Michael R.) with a tweaked note.  Rationale being that if you used what 
I suggested you'd have to make sure two registries were updated if a 
change was made to the registry at some later time. i.e.,:

Value
-----
27
...
y

Group
-----
Reserved for 802.11 Brainpool Group 1
...
Reserved for 802.11 Brainpool Group n

Description
-----------
This specification
...
This specification

Notes
-----
Only for 802.11 - Not for use with IKEv1
Only for 802.11 - Not for use with IKEv1
Only for 802.11 - Not for use with IKEv1

spt

* I say preferred because you can try another approach if you want.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 19 Oct 2012 00:06:24 -0700 (PDT)

Sean,

  The thing is, they're not just for 802.11. RFC 5931 uses them too.

  Dan.

On Thu, October 18, 2012 9:12 am, Sean Turner wrote:
>>>>>     Can you ask the IESG to just do what it has done in the past?
>>>>> That
>>>>> is,

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 19 Oct 2012 00:20:43 -0700 (PDT)

Sean,

  It was a two-part request. I'd like the IESG to follow the same process
they followed for what became RFC 5114.

  Is there a way to get an RFC published to update this registry that
does not need to go through the IESG? If not then the 2nd part is
the critical one; if so then we can just end this fiasco now.

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 19 Oct 2012 15:54:14 -0700 (PDT)

Hi Michael,

On Fri, October 19, 2012 6:08 am, Michael Richardson wrote:
>
>>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
>     Dan> The thing is, they're not just for 802.11. RFC 5931 uses them
>     Dan> too.
>
> But, you don't use the values from the IKEv1 registry do you?
> It might use the curves themselves, but it doesn't identify them using
> the IKEv1 registry.  At least, that all I could tell where/how from
> brief reading of IANA considerations, and some searches.

  Section 3.2.1 says,

     "The Group Description field value is taken from the IANA registry
      for 'Group Description' created by IKE [RFC2409]."

That's how groups are identified, by a ushort whose value comes
out of this registry. For EAP-pwd to use brainpool curves it will be
necessary for the registry to not restrict it from using them (i.e. it
can't say "for 802.11 only").

> (ps: it's a well written security considerations)

  Thank you!

  Dan.

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>
>
>

---

From: Sean Turner <[email-masked]>
Date: Sun, 21 Oct 2012 12:20:08 -0400

Dan,

Yes - you can ask the ISE (https://www.rfc-editor.org/indsubs.html) to 
publish.

spt

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Oct 2012 14:25:31 +0300

> Yes - you can ask the ISE (https://www.rfc-editor.org/indsubs.html) to 

I am not sure if that helps, as RFC 5742 section 3 will still put it
to IESG, and IESG still needs to consider the document and decide
which conclusion it will come with it:

----------------------------------------------------------------------
   The IESG review of these Independent Submission and IRTF stream
   documents results in one of the following five types of conclusion,
   any of which may be accompanied by a request to include an IESG note
   if the document is published.

   1. The IESG has concluded that there is no conflict between this
      document and IETF work.

   2. The IESG has concluded that this work is related to IETF work done
      in WG <X>, but this relationship does not prevent publishing.

   3. The IESG has concluded that publication could potentially disrupt
      the IETF work done in WG <X> and recommends not publishing the
      document at this time.

   4. The IESG has concluded that this document violates IETF procedures
      for <Y> and should therefore not be published without IETF review
      and IESG approval.

   5. The IESG has concluded that this document extends an IETF protocol
      in a way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.
----------------------------------------------------------------------

If those numbers are added to "Internet Key Exchange (IKE) Attributes"
registry (hey, there is new xml version of the registry
http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xml)
then that would clearly be related to the IPsecME WG. This means IESG
still needs to consider the document and decide whether it comes to
conclusion 2 or 3. I.e. the document will still be considered by the IESG.

Dan's question asked whether he can publish the RFC without it needing
to go through the IESG, and I think for this specific item the answer
is no, as there clearly is WG which this work is related to.

>> the critical one; if so then we can just end this fiasco now.

I think it would be better (and faster) to solve this here and now,
than waste time through the independent submission stream.
-- 
[email-masked]

---

From: Sean Turner <[email-masked]>
Date: Mon, 22 Oct 2012 08:26:17 -0400

Dan,

I've exchange some emails with with Johannes Merkle about adding cipher 
suites to TLS.  What he's agreed to do is to include only three points 
(BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft.

spt