I also support something is being done in this direction. I like the idea of taking ephemeral non allocated code points.
What is not so clear to me is how GREASE prevents a buggy implementations from behaving correctly for GREASE allocated code points, while remaining buggy for the other (unallocated). code points. Yours, Daniel On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini <alessan...@ghedini.me> wrote: > On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: > > Hi all, > > > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > > ossification problems. > > > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be > > incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet > > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > > ClientHello, so versioning moved to supported_versions. Widespread > > non-compliant middleboxes attempted to parse someone else’s ServerHellos, > > so the protocol was further hacked to weave through their many defects. > > > > I think I can speak for the working group that we do not want to repeat > > this adventure again. In general, I think the response to ossification is > > two-fold: > > > > 1. It’s already happened, so how do we progress today? > > 2. How do we avoid more of this tomorrow? > > > > The workarounds only answer the first question. For the second, TLS 1.3 > has > > a section which spells out a few protocol invariants > > <https://tlswg.github.io/tls13-spec/draft-ietf-tls- > tls13.html#rfc.section.9..3>. > > It is all corollaries of existing TLS specification text, but hopefully > > documenting it explicitly will help. But experience has shown > specification > > text is only necessary, not sufficient. > > > > For extensibility problems in servers, we have GREASE > > <https://tools.ietf.org/html/draft-ietf-tls-grease-01>. This enforces > the > > key rule in ClientHello processing: ignore unrecognized parameters. > GREASE > > enforces this by filling the ecosystem with them. TLS 1.3’s middlebox > woes > > were different. The key rule is: if you did not produce a ClientHello, > you > > cannot assume that you can parse the response. Analogously, we should > fill > > the ecosystem with such responses. We have an idea, but it is more > involved > > than GREASE, so we are very interested in the TLS community’s feedback. > > > > In short, we plan to regularly mint new TLS versions (and likely other > > sensitive parameters such as extensions), roughly every six weeks > matching > > Chrome’s release cycle. Chrome, Google servers, and any other deployment > > that wishes to participate, would support two (or more) versions of TLS > > 1.3: the standard stable 0x0304, and a rolling alternate version. Every > six > > weeks, we would randomly pick a new code point. These versions will > > otherwise be identical to TLS 1.3, save maybe minor details to separate > > keys and exercise allowed syntax changes. The goal is to pave the way for > > future versions of TLS by simulating them (“draft negative one”). > > > > Of course, this scheme has some risk. It grabs code points everywhere. > Code > > points are plentiful, but we do sometimes have collisions (e.g. 26 and > 40). > > The entire point is to serve and maintain TLS’s extensibility, so we > > certainly do not wish to hamper it! Thus we have some safeguards in mind: > > > > * We will document every code point we use and what it refers to. (If the > > volume is fine, we can email them to the list each time.) New allocations > > can always avoid the lost numbers. At a rate of one every 6 weeks, it > will > > take over 7,000 years to exhaust everything. > > > > * We will avoid picking numbers that the IETF is likely to allocate, to > > reduce the chance of collision. Rolling versions will not start with > 0x03, > > rolling cipher suites or extensions will not be contiguous with existing > > blocks, etc. > > > > * BoringSSL will not enable this by default. We will only enable it where > > we can shut it back off. On our servers, we of course regularly deploy > > changes. Chrome is also regularly updated and, moreover, we will gate it > on > > our server-controlled field trials > > <https://textslashplain.com/2017/10/18/chrome-field-trials/> mechanism. > We > > hope that, in practice, only the last several code points will be in use > at > > a time. > > > > * Our clients would only support the most recent set of rolling > parameters, > > and our servers the last handful. As each value will be short-lived, the > > ecosystem is unlikely to rely on them as de facto standards. Conversely, > > like other extensions, implementations without them will still > interoperate > > fine. We would never offer a rolling parameter without the corresponding > > stable one. > > > > * If this ultimately does not work, we can stop at any time and only have > > wasted a small portion of code points. > > > > * Finally, if the working group is open to it, these values could be > > summarized in regular documents to reserve them, so that they are > > ultimately reflected in the registries. A new document every six weeks is > > probably impractical, but we can batch them up. > > > > We are interested in the community’s feedback on this proposal—anyone who > > might participate, better safeguards, or thoughts on the mechanism as a > > whole. We hope it will help the working group evolve its protocols more > > smoothly in the future. > > This looks interesting and I very much agree that we should do *somthing* > to > try to avoid the pain we've seen with deploying TLS 1.3 for future > versions. > > We (Cloudflare) would be happy to help with developing and deploying it, > and > see how the experiment goes (and maybe even help put a draft together if > needed, > if that is the form this proposal will take). > > Cheers > > _______________________________________________ > 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
