Intent to Ship: Draft TLS 1.3 1-RTT field trial, take two
David Benjamin
Contact emails
davi...@chromium.org, sva...@chromium.org
Spec
https://tools.ietf.org/html/draft-ietf-tls-tls13-22
(TAG review N/A. This is a network protocol under the IETF, not a web platform API under the W3C.)
Summary
Ship TLS 1.3 draft-22 in 1-RTT mode. This is to provide a stable TLS 1.3 baseline for experimenting with 0-RTT and testing out deployability of various features of the protocol.
Link to “Intent to Implement” blink-dev discussion
This is a continuation to our efforts last year. The differences from there are:
We are now targeting draft-22, not draft-18.
Single-use tickets are now implemented
RSA client certificates are now supported, on platform + smartcard combinations that can provide RSA-PSS. (See below.)
We have experience with and mitigations for middlebox defects. See details below.
0-RTT will be covered in a separate Intent, once we have a TLS 1.3 baseline. We continue to have no plans to implement ECDH-less PSK resumption, FFDH groups, or post-handshake authentication.
Link to Origin Trial field trial feedback summary
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/, slide 11.
See Interoperability and Compatibility below for details.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes. This is all platform-independent, except...
Client certificates in Chrome use OS APIs to interact with platform key store and smartcards. TLS 1.3 switches RSA from PKCS#1 v1.5 to PSS signatures, so client certificate deployments must ensure their client base supports PSS to use TLS 1.3. Windows, macOS >= 10.13, Linux, and Android >= N support PSS (supposing the underlying smartcard implements it). We support PSS signatures on those platforms. On Chrome OS, we support PSS with the built-in key store. https://crbug.com/792204 tracks adding it to the chrome.certificateProvider extension API, but the limiting factor is generally going to be the smartcard.
(Note client certificates are not a web platform feature in the usual sense. They’re a funny authentication mechanism used by some organizations.)
Debuggability
The security panel reports what TLS version was used.
Risks
Interoperability and Compatibility
There are many sources of compatibility risk to consider with a change like this.
First, existing servers may be buggy and reject the extended 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. Our experience deploying earlier iterations indicates that this was successful. We’ve had TLS 1.3 clients running on Beta for all of 2017 with no such issues.
Second, middleboxes (firewalls, proxies, etc.) may break when client and server both support TLS 1.3. Such middleboxes are non-compliant and did not implement TLS 1.2 correctly. (An analogy for web platform folks: imagine if some firewall or proxy broke the connection when it saw an unrecognized HTTP header.) Alas, our experience deploying earlier iterations is that this is a huge problem, which is why our draft-18 deployment was aborted. An early round of measurement on beta showed a 1.7% baseline handshake failure rate towards a TLS-1.3-capable service turn into 7.7% failures!
We’ve been using the intervening time experimenting with alternate encodings of TLS 1.3 that work around these buggy middleboxes. We believe we’ve succeeded. Our experiments, running in M63, show a 1.4% baseline handshake failure rate turning into 1.2% on Beta. We presented these results at the IETF 100 meeting. The changes were accepted into draft-22, which we intend to ship here.
Stable and beta populations differ, so there is a chance that our successes will not translate to the stable channel. M63 is currently shipping to stable, where our experiments will continue. We will monitor both the M63 stable experiment and draft-22 as it makes it through the release pipeline. Draft-22 will be gated on a field trial as before, so, in case of problems, we can halt deployment and reevaluate from there.
Third, we are shipping a draft version of a still-developing protocol. It is ultimately doomed to be replaced by later drafts and ultimately the final RFC. Each snapshot of TLS has different version numbers (0304 for final and 7f𝑥𝑥 for drafts), so 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. 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.
Finally, there is a risk of interoperability problems at the same draft version. Other implementers have been working on TLS 1.3 draft implementations, and we successfully interoperated with various other stacks at the IETF 100 hackathon, thus we believe the risk there is minimal. In the worst case, if 7f16 (draft-22) becomes stuck due to widely-deployed implementation bugs, it was doomed to be replaced with 0304 anyway.
Edge: Public support
Firefox: In development
Safari: In development
Web developers: OpenSSL, Cloudflare
Ergonomics
TLS 1.3 is a network protocol, so it is largely abstracted away from the web platform. It does enable 0-RTT which is a bit more developer-visible, but that will be shipped separately once we have a baseline.
Activation
This is a network protocol and thus inherently requires server software changes. As with draft-18 before, we do not expect TLS 1.3 draft-22 will be deployed beyond a few early adopters. Rather, this is part of real-world testing which is important for the developing protocol (we would not have learned of the buggy middleboxes otherwise). Once the final RFC is published, we will ship that, and web developers should gradually get draft-22 as their server software or hosting provider ships the update.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
No. See here for issues with using web-platform-tests for this right now. Instead, we have very thorough test suite in BoringSSL. Other stacks have even had some success in using it.
Entry on the feature dashboard
Blink folks, I’ll need your advice on this one. Here is the original entry we filed. It claims we shipped TLS 1.3 in M56, which was the original timeline, but that didn’t work thanks to buggy middleboxes. The planned timeline is:
M56: Draft-18 via field trials. Rolled back due to middleboxes.
M57 through M62: Various experiments to figure out what would actually be deployable.
M63: The experimental variant that finally succeeded, again via field trials. (Though, of course, each of these experiments necessarily entails shipping something.)
M65: Draft-22 via field trial.
M??: Later drafts via field trial if they exist and are worth snapshotting. I don’t expect there to be many of these as this middlebox issue was basically the last blocker.
M??: Final RFC via field trial, whenever that is published.
M??: Final RFC turned on by default in code. (This is basically a no-op for Chrome, but potentially different to other Chromium derivatives.)
At each point we ship some snapshot, we’re going to unship the previous one, until the final RFC when things are all done. So, the question is, how many feature dashboard entries do you want, and which status? Should we keep updating the previous one, or keep adding new ones that say basically the same thing?
Jacob G
David Benjamin
It will be soon. None of those is draft-22 yet (rather, they're the experiments with led to draft-22). We have an implementation of draft-22 proper in BoringSSL, but the CL to hook it up to Chromium's about:flags is still waiting on one more reviewer stamp.
On Wed, Dec 6, 2017 at 4:36 AM Jacob G <kurte...@gmail.com> wrote:
Is this part of about:flags, if yes, which of the 3 experiments? (#tls13-variant)
--
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+u...@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/c66541f8-e6c6-42a8-818f-28e521af0469%40chromium.org.
David Benjamin
Is this part of about:flags, if yes, which of the 3 experiments? (#tls13-variant)
--
Joe Medley
(Sending from the right address this time. Looks like the original email made it to net-dev and security-dev, but not blink-dev?)
On Wed, Dec 6, 2017 at 11:13 AM David Benjamin <davi...@google.com> wrote:
It will be soon. None of those is draft-22 yet (rather, they're the experiments with led to draft-22). We have an implementation of draft-22 proper in BoringSSL, but the CL to hook it up to Chromium's about:flags is still waiting on one more reviewer stamp.
On Wed, Dec 6, 2017 at 4:36 AM Jacob G <kurte...@gmail.com> wrote:
Is this part of about:flags, if yes, which of the 3 experiments? (#tls13-variant)--
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/c66541f8-e6c6-42a8-818f-28e521af0469%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBnRNEbJiSV6zxhxmr%2BY9dy860y9q7uG2vsQHXwStAJGA%40mail.gmail.com.
Adam Langley
Can I get a tracking bug so I can follow the progress of this?
Yoav Weiss
--
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+u...@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/CAF8qwaAF5cuTZtGGf4ErQpuUvKHngsds59hOZb2%2BRROrDuMTGQ%40mail.gmail.com.
David Benjamin
Harald Alvestrand
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/CAF8qwaAF5cuTZtGGf4ErQpuUvKHngsds59hOZb2%2BRROrDuMTGQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjA%3DPD6khWW_KKLeDUDu5hau2pqgNrBWaSyneDsHwEMcw%40mail.gmail.com.
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@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/CAF8qwaAF5cuTZtGGf4ErQpuUvKHngsds59hOZb2%2BRROrDuMTGQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Rick Byers
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/CAF8qwaAF5cuTZtGGf4ErQpuUvKHngsds59hOZb2%2BRROrDuMTGQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjA%3DPD6khWW_KKLeDUDu5hau2pqgNrBWaSyneDsHwEMcw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgZizG2OtpXa%3DsX-coj7WkTVYG_xkD%2BrBM_bQKpq91G7w%40mail.gmail.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFUtAY-APs2sr%2Bq-B3Q8uU9MJVE4QH5hRmLJtUk%2Btv-MJO%2BnDw%40mail.gmail.com.
David Benjamin
LGTM2I'd suggest just updating the one Chromestatus entry. Most web devs aren't going to care about the status of various stages along the way (and the few people who do should be able to click through to the bug status for details).
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@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/CAF8qwaAF5cuTZtGGf4ErQpuUvKHngsds59hOZb2%2BRROrDuMTGQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjA%3DPD6khWW_KKLeDUDu5hau2pqgNrBWaSyneDsHwEMcw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.