David,
Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to make
via the IANA considerations section. They enforce the registry policy
established when we (the IETF/TLS WG) originally established the registry; the
available policies are found in RFC 5226 (and there’s some more rules in RFC
7120). So, I’m hoping that you could tweak your draft somewhat to be
instructional and then suggest some values (this purely procedural dance has
worked in the past and it’s what we’re doing for draft-ietf-tls-ecdhe-psk-aead):
0) In s2, replace the two lists with something like:
The draft reservers the following X cipher suite values: Values TBD
The following X values are reserved as both GREASE extension values and GREASE
named group values: Values TBD
1) In 5, add a {TBD} sub-column to the 1st column for each value in the tables
(apologies for the formatting):
+-------------------------+-------------+---------+-----------------+
| Value | Description | DTLS-OK | Reference |
+-------------------------+-------------+---------+-----------------+
| {TBD} {0x0A,0x0A} | Reserved | Y | (this document) |
And then add something like this to the end of the section:
The cipher suite numbers listed in the second column in the
values column are numbers used for cipher suite interoperability
testing and it's suggested that IANA use these values for assignment.
I’m sure somebody will eventually comment on the following header fields:
0) “Status: Informational” because some of the registries right now require
standards track RFCs to do the assignments. But, everybody should momentarily
suspend reality because we’re going to change the registry rules for the
registries you are adding values you to be something that would allow an draft
intended for “informational” to do the updates, i.e., just leave it alone for
now.
1) “Updates: 5246 (if approved)” because typically extension documents don’t
“update” the base specification. If you are suggesting that all
implementations must support these values then an updates header makes sense.
Note I’m sure somewhere along the way an extension that isn’t expected to be
supported by all implementation has an updates header but what I described is
how we’re doing it now.
Cheers,
spt
PS: As chair, I try to deal with/deflect as many of these procedural issues as
possible, but if you want to know more please let me know off-list. This
actually goes for anybody on the list.
> On Jul 25, 2016, at 18:32, David Benjamin <david...@chromium.org> wrote:
>
> Hi folks,
>
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft-davidben-tls-grease-00
>
> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analogy
> from https://www.imperialviolet.org/2016/05/16/agility.html )
>
> One problem we repeatedly run into is servers failing to implement TLS's
> various extension points correctly. The most obvious being version
> intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
> implementation. (Thankfully it was rare enough to not warrant a fallback or
> revert!) It appears that signature algorithms maybe also be gathering rust.
> Ciphers and extensions seem to have held up, but I would like to ensure they
> stay that way.
>
> The root problem here is these broken servers interoperate fine with clients
> at the time they are deployed. It is only after new values get defined do we
> notice, by which time it is too late.
>
> I would like to fix this by reserving a few values in our registries so that
> clients may advertise random ones and regularly exercise these codepaths in
> servers. If enough of the client base does this, we can turn a large class of
> tomorrow's interop failures into today's interop failures. This is important
> because an bug will not thrive in the ecosystem if it does not work against
> the current deployment.
>
> If you were in Berlin, you may recognize this idea from the version
> negotiation debate. Alas that all happened in the wrong order as I hadn't
> written this up yet. This idea can't be applied to versioning without giving
> up on ClientHello.version, but we can start with the rest of the protocol.
>
> David
>
> PS: This is actually my first I-D, so apologies if I've messed it up
> somewhere!
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
