Intent to Ship: Draft TLS 1.3 1-RTT field trial

171 views
Skip to first unread message

David Benjamin

unread,
Oct 25, 2016, 2:49:05 PM10/25/16
to blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org

(This is using the Intent to Implement and Ship template because I forgot to send the Intent to Implement. But since we’ve been working on it for two quarters now, it seemed unreasonable to say “Intent to Implement” in the subject.)


Contact emails

Eng: davi...@chromium.org, nha...@chromium.org, sva...@chromium.org

PM: awha...@chromium.org


Spec

https://tools.ietf.org/html/draft-ietf-tls-tls13-16


Summary

Ship TLS 1.3 in 1-RTT mode under a field trial. We are currently implementing draft 16, linked above.


Motivation

TLS 1.3 is a major revision of the TLS protocol. It has a new handshake with a simpler, more modern design and improved security. (Resumption is still forward-secure and more of the handshake is encrypted). It also enables a new feature, 0-RTT, inspired by the same feature in QUIC, which allows application data to be sent in the first round-trip. Ultimately, we intend to ship the final version of TLS 1.3, ship 0-RTT, and even replace QUIC’s crypto handshake with TLS 1.3.


We have been working on our TLS 1.3 implementation in BoringSSL and are helping to define the new protocol at the IETF. We are now ready to ship a draft version of the protocol as the first stage of this project. For this stage, we are interested in deployment experience with the new protocol. In particular, we wish to determine if buggy servers and middleboxes will cause problems. This also gives us a starting point for future work.


For a change like this, it is important to have deployment experience before the protocol is done, which is why we are shipping a draft version. This helps guide the protocol’s development, like renumbering RSA-PSS last cycle.


Details

We will support the corresponding parameters of our TLS 1.2 implementation in TLS 1.3 (absent those removed in 1.3). TLS 1.3 allows the basic handshake to complete in one round-trip with client-predicted ECDH curves. On misprediction, the server sends HelloRetryRequest and we complete in two roundtrips. Our implementation sends X25519 in the initial ClientHello and requires an extra roundtrip for legacy curves.


As this is an initial deployment of a draft version, we will not be supporting the following:


  • 0-RTT

  • Single-use tickets

  • RSA client certificates

  • ECDH-less PSK resumption

  • FFDH groups

  • Post-handshake authentication


We’ll add support for 0-RTT, single-use tickets, and RSA client certificates later on in this project. Note that although reusing tickets in TLS 1.3 allows correlating some connections, this is the same as in TLS 1.2. Rather, this experiment will in part be to gather metrics on how many parallel tickets to issue or retain.


We have no plans to implement ECDH-less PSK resumption or FFDH groups.


As the project progresses, our implementation will be updated to later drafts and ultimately be replaced by the final version when the protocol is done. (See below for interoperability considerations.)


Interoperability and Compatibility Risk

There are many sources of compatibility risk to consider with a change like this.


First, we may have deployment problems with the existing ecosystem. Although the protocol is defined extensibly, buggy servers may reject the new ClientHello. Historically, this has been a problem with new TLS versions. Guided by this experience and data probing sites, TLS 1.3 switches to a more flexible versioning scheme which avoids these problems. However, there may always be unforeseen issues. There is additional risk that some network middleboxes will reject connections using the new protocol.


Accordingly, TLS 1.3 will be gated on a field trial. We will be monitoring the error rate between TLS 1.3 and control groups as the change progress through release channels. If necessary, we can halt the experiment and try to revise the protocol based on what we’ve learned.


Second, we are shipping a draft version of a still-developing protocol. The new versioning scheme gives different numbers for each iteration (0304 for final and 7f𝑥𝑥 for drafts). Thus servers deploying different drafts or the final version will instead select the common TLS 1.2 and work fine. This is analogous to how HTTP/2 was deployed with ALPN.


Relatedly, we are shipping something which is destined to be replaced. However, the risk that sites will rely on a draft version is negligible. Any site negotiating a draft version of TLS 1.3 must also support TLS 1.2 or be incompatible with other browsers and our own control group.


Finally, the risk of interoperability problems at the same draft version is low. Other implementers have been working on TLS 1.3 draft implementations, and we successfully interoperate with existing draft 16 stacks. Mozilla also recently announced an intent to ship draft TLS 1.3.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

https://crbug.com/630147


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5712755738804224

Jana Iyengar

unread,
Oct 25, 2016, 3:06:18 PM10/25/16
to David Benjamin, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
W00t! It's great to see this getting shipped!

I believe that Firefox is currently shipping TLS1.3 under a user-controllable flag, and is planning to ship TLS1.3 on by default in the next few months, but they don't have extensive field trials. Chrome's extensive field-trial framework will add significant value to TLS 1.3 development and deployment, so I welcome this field trial. In the server ecosystem, I believe CloudFlare has deployed the current draft version, so this trial should give us experience with use of TLS 1.3 as well as for fallback to TLS 1.2.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAF8qwaB9isekTeLesHagJ6S6sa7gzokzmsNBOQv5gk-bOrDunw%40mail.gmail.com.

Rick Byers

unread,
Oct 25, 2016, 3:17:31 PM10/25/16
to Jana Iyengar, David Benjamin, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
LGTM1

The combination of finch, protocol versioning / fallback and careful attention to metrics makes the compat and interop risks much lower than the more-typical new APIs we do.  Good luck!

David Benjamin

unread,
Oct 25, 2016, 3:20:33 PM10/25/16
to Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
Just to clarify a bit on the "fallback to TLS 1.2" phrasing, since "fallback" probably means different things to different people:

There's "fallback" in so far as TLS 1.2 (or earlier) servers, if not buggy, will respond with TLS 1.2 (or earlier) in response to a TLS 1.3 ClientHello. TLS is designed so that newer ClientHellos are meaningful at older versions. We aren't removing any existing versions at this time, so Chrome will continue to accept older ones fine.

Then there's the insecure TLS version fallback. That was a workaround browsers used to do against buggy servers that causes security problems. We removed that earlier this year and do not plan on restoring it. (That was a motivation for the new versioning scheme. The previous one, empirically, did not work.)

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

David Benjamin

unread,
Oct 25, 2016, 4:43:41 PM10/25/16
to Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
Blink folks: it looks like chromestatus.com doesn't quite have a dropdown for field trials. Would it be better to call this an "Origin trial" on grounds that it has the word "trial" in it or just say "Enabled by default" with the description saying we'll be controlling deployment via field trials?

Philip Jägenstedt

unread,
Oct 26, 2016, 7:24:36 AM10/26/16
to David Benjamin, Jana Iyengar, jme...@google.com, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org

Mike West

unread,
Oct 26, 2016, 7:44:18 AM10/26/16
to Philip Jägenstedt, David Benjamin, Jana Iyengar, jme...@google.com, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
Non-owners' LGTM for this experiment. I'm looking forward to gaining some interop experience with TLS 1.3, and starting with the straightforward pieces seems like a great plan that minimizes compatibility risks.

-mike

On Wed, Oct 26, 2016 at 1:24 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

I'm not Joe, but IMO it's probably worth adding an explicit "In Field Trial" or something similar, but for the moment "behind a flag" seems accurate; we just happen to turn the flag on by default for some subset of users. :)

-mike

Philip Jägenstedt

unread,
Oct 26, 2016, 10:31:46 AM10/26/16
to Mike West, David Benjamin, Jana Iyengar, jme...@google.com, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
LGTM2, forgot :)

Jochen Eisinger

unread,
Oct 26, 2016, 10:32:47 AM10/26/16
to Philip Jägenstedt, Mike West, David Benjamin, Jana Iyengar, jme...@google.com, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
lgtm3

Rick Byers

unread,
Oct 26, 2016, 11:40:10 AM10/26/16
to Philip Jägenstedt, David Benjamin, Jana Iyengar, jme...@google.com, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
I wouldn't overload "origin trial" for this - that implies there won't be any change unless the developer explicitly opts-in.

I think it's fine to just call this "enabled by default" as developers can expect to see users getting it without any explicit action.  The fact that not all users will get it is probably a detail that won't matter to most.  If we think it's important to communicate this (beyond simply mentioning it in the comments) then I'm sure we could easily add a new option for it to chromestatus.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

Joe Medley

unread,
Oct 26, 2016, 11:56:49 AM10/26/16
to Mike West, Philip Jägenstedt, David Benjamin, Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org

On Wed, Oct 26, 2016 at 4:43 AM, Mike West <mk...@chromium.org> wrote:
"behind a flag" seems accurate

Can it be turned on and off by developers like any other flag?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

David Benjamin

unread,
Oct 26, 2016, 12:22:48 PM10/26/16
to Joe Medley, Mike West, Philip Jägenstedt, Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
On Wed, Oct 26, 2016 at 11:56 AM 'Joe Medley' via net-dev <net...@chromium.org> wrote:

On Wed, Oct 26, 2016 at 4:43 AM, Mike West <mk...@chromium.org> wrote:
"behind a flag" seems accurate

Can it be turned on and off by developers like any other flag?

Yes, but that's true of many features, whether they're on or off by default. I don't think we'd call something on fully by default but disable-able by a flag as "behind a flag".

I think I like Rick's argument. The salient point here is probably that TLS 1.3 will be advertised without user action, which matches "enabled by default". (And that the field trial is primarily a deployment strategy on our end.) I've set it to that one.

David 

Joe Medley

unread,
Oct 26, 2016, 12:26:45 PM10/26/16
to David Benjamin, Mike West, Philip Jägenstedt, Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org

On Wed, Oct 26, 2016 at 9:21 AM, David Benjamin <davi...@chromium.org> wrote:
The salient point here is probably that TLS 1.3 will be advertised without user action, which matches "enabled by default". (And that the field trial is primarily a deployment strategy on our end.) I've set it to that one.

That sounds right to me. In general, if there's nothing actionable from a web developer's point of view it doesn't need to be in status, updates/, mdn, etc..

David Benjamin

unread,
Nov 18, 2016, 8:18:05 PM11/18/16
to Joe Medley, Mike West, Philip Jägenstedt, Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
Apologies, I forgot to update this thread. A small addendum to the original mailing: we will be experimenting with draft 18 rather than draft 16, specification link here:

It's still essentially the same protocol, with some tweaks. This aligns us better with the draft version Firefox will be experimenting at and, should this run go well, makes it easier to experiment with 0-RTT next. (Draft 18 avoids an extra key change when offering 0-RTT data and slightly simplifies the key schedule.)

I have updated the feature dashboard entry accordingly.

David Benjamin

unread,
Jul 11, 2017, 3:06:50 PM7/11/17
to Joe Medley, Mike West, Philip Jägenstedt, Jana Iyengar, blink-dev, net-dev, security-dev, Nick Harper, sva...@chromium.org, awha...@chromium.org
To follow-up here, we were unable to deploy the draft TLS 1.3 as planned due to high error rates caused by bugs in middleboxes throughout the ecosystem. To guide our next steps and feedback to the IETF, we will be running some experiments to better understand these bugs and the problems they are causing.
Reply all
Reply to author
Forward
0 new messages