(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
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
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5712755738804224--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
+Joe Medley, WDYT?
+Joe Medley, WDYT?
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
"behind a flag" seems accurate
On Wed, Oct 26, 2016 at 4:43 AM, Mike West <mk...@chromium.org> wrote:"behind a flag" seems accurateCan it be turned on and off by developers like any other flag?
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.