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
On 10/19/12 3:20 AM, Dan Harkins wrote:
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.
On Thu, October 18, 2012 7:58 am, Sean Turner wrote:
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
On 10/15/12 10:54 PM, Dan Harkins wrote:
Hi Sean,
On Mon, October 15, 2012 5:00 pm, Sean Turner wrote:
On 10/12/12 2:32 AM, Dan Harkins wrote:
On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
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.
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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
