Re: [TLS] Keeping TLS extension points working

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 <davidben@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