Re: Intent to implement and ship: TLS 1.3 certificate compression with Brotli

[David Benjamin]

As additional motivation, this is part of the path towards QUIC standardization. QUIC has certificate compression today, which is particularly useful in some DoS scenarios. (QUIC can send certificates a roundtrip earlier than TCP, so the protocol must worry about amplification.) The future standardized version of QUIC will use TLS 1.3. This extension allows that future to maintain feature parity.

On Fri, Jul 6, 2018 at 2:16 PM Adam Langley <a...@chromium.org> wrote:

Contact emails

a...@chromium.org

Spec

https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-03

Summary

TLS 1.3 encrypts the server's certificates. With that protection in place, we finally have the confidence that we can implement certificate compression without causing middlebox issues.

Certificate compression is an IETF TLS WG draft and we plan on implementing that specification, supporting the Brotli algorithm.

This feature is negotiated with the TLS server for each connection. We have high confidence that advertising support for certificate compression will not cause problems itself because we often add new TLS extensions (and have active GREASEing of them).

This feature will be transparent to web developers: if their server implements certificate compression it will save a few bytes of TLS handshake but everything will otherwise be the same.

Motivation

X.509 certificates are not terribly compact and dominate the TLS handshake when sent. Compressing them has been a desiderata for many years but it's only now, with TLS 1.3, that we think it viable. The savings are modest (mail.google.com saves 553 bytes per handshake right now), but every little helps—especially as the number of third-party sub-resources used by sites, and thus the number of resulting TLS handshakes, increases.

Interoperability risk

Firefox: No public signals

Edge: No public signals

Safari: No public signals

We can disable this feature at will as TLS will automatically fall back to sending uncompressed certificates.

Compatibility risk

We often ship new TLS extensions without breaking existing servers therefore we do not expect any issues here.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes: it'll take effect wherever we ship the Chromium network stack and don't explicitly disable Brotli support.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=860767

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5696925844111360

Requesting approval to ship?

Yes.

Cheers

AGL

[Adam Langley]

[Philip Jägenstedt]

LGTM1

I'm not any kind of expert in this area, but the summary makes sense.

The template asks "Request a tag review and include a link or comment on why the tag review process is being skipped." The reason to skip it in this case, I think, is that this is below the level in the stack where the TAG operates, and a fairly small change as well.

The template also asks "Is this feature fully tested by web-platform-tests?" and TLS itself just isn't tested by web-platform-tests at all right now, although it is used for HTTPS tests. I don't propose to fix that today, but wonder if there is any kind of shared testing for TLS? Is our implementation tested entirely by unit tests, or would there be a path to share the tests with other browsers vendors if only some infrastructure for it existed?

--
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/CAF8qwaBKHw1w%2BJTyW6KBvd7Cr7qsyhzO75J8enROTdfYSz4VVA%40mail.gmail.com.

[Daniel Bratell]

I am also not any kind of expert in this area so please forgive me if I ask basic/stupid questions:

The Intent lists "no signals" from any other vendor. Have anyone asked them or at least filed a bug in their bug databases?

Similar to Philip's question but more general (or maybe the same), what ensures implementation interoperability today?

The RFC is classified as a draft that expires in a month. How stable is it?

We've seen in other security areas that compression has leaked information since not all data is equally compressible. That is not mentioned in the security section of the spec. Is it an oversight or is this completely irrelevant (I warned that the questions might be stupid!)

/Daniel

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/CAJ_uWHtz%3D-H-v81LZK12h6VW3PzqTh1-Nv__9bkFrJCa3Vpz_w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[David Benjamin]

On Wed, Jul 11, 2018 at 10:20 AM Daniel Bratell <bra...@opera.com> wrote:

I am also not any kind of expert in this area so please forgive me if I ask basic/stupid questions:

The Intent lists "no signals" from any other vendor. Have anyone asked them or at least filed a bug in their bug databases?

The draft was presented at a TLSWG meeting at IETF98 with a "good strong hum" for adoption and "crickets" for no adoption.

https://datatracker.ietf.org/doc/minutes-98-tls/

Relevant folks from vendors are active at the TLSWG. Here is the thread on the list confirming adoption, with support from relevant folks at Akamai, Apple, and Mozilla. The draft was also cowritten by someone at Cloudflare. But I must emphasize here that folks at the IETF participate individually and not as organizations, so take this to mean individual folks' interest and not signals from the vendors themselves.

https://www.ietf.org/mail-archive/web/tls/current/msg23293.html

I've filed a ticket at Mozilla's standards-positions repository for a more official signal.

https://github.com/mozilla/standards-positions/issues/96

 

Similar to Philip's question but more general (or maybe the same), what ensures implementation interoperability today?

The RFC is classified as a draft that expires in a month. How stable is it?

Certificate compression went through early code point assignment, which requires that the specification be considered stable.

https://tools.ietf.org/html/rfc7120

Should we discover an issue later on and find we need to change things incompatibly, we would just pick a new code point. Unlike HTTP headers or JavaScript APIs, code points are opaque numbers and not meaningful strings. If we lose code point 27, there are over 65,000 more to chose from. (In fact the extension was originally allocated code point 26, but it turned out someone had already squatted that code point, so now it's 27.)

 

We've seen in other security areas that compression has leaked information since not all data is equally compressible. That is not mentioned in the security section of the spec. Is it an oversight or is this completely irrelevant (I warned that the questions might be stupid!)

That's a reasonable question. Compression is interesting because encryption does not hide lengths, it only hides content. As compression's entire purpose is to change length based on content, there is indeed a mismatch here. This gets especially fun when one compresses secret data and externally-supplied data together, since one can vary the latter to learn things about the former based on length.

The latter is not a concern here, as the server is compressing credentials it is configured with. As the draft notes:

   Since certificate chains are typically presented on a per-server name

   or per-user basis, the attacker does not have control over any

   individual fragments in the Certificate message, meaning that they

   cannot leak information about the certificate by modifying the

   plaintext.

As for secrecy of the data in general, TLS 1.3 does indeed encrypt certificates. (Unlike TLS 1.2 which does not. Between the cleartext SNI and DNS, we have not really solved the problem of hiding who you are talking to, only what you are saying. TLS 1.3's certificate encryption is step here, but not especially effective standalone.) The question is whether compression changes whether lengths are interesting.

If you consider the server certificate secret, you already must deal with differing lengths in certificates, likely by using TLS 1.3's padding mechanism. If you have certificates A, B, and C, you might pad them up to max(len(A), len(B), len(C)). Compression is compatible with this. You might pad up to max(len(compress(A)), len(compress(B)), len(compress(C))), which one expects is still smaller. (Or you could decide compression is not a good fit for your deployment and not support it on the server.)

This was discussed a bit on the TLS list here, though perhaps it's worth some text in the spec (+vasilvv).

https://www.ietf.org/mail-archive/web/tls/current/msg22867.html

https://www.ietf.org/mail-archive/web/tls/current/msg22872.html

https://www.ietf.org/mail-archive/web/tls/current/msg22874.html

[Matthew Menke]

Is there any size limit here?  Admittedly, browser OOMs are perhaps not the biggest concern in the world, just wondering if we have some sort of mitigation for it.  For body data, we only decompress as much as will fit into the IPC buffer at a time, which means you'll generally, at worst, OOM the renderer with a compression bomb.

[David Benjamin]

The CompressedCertificate message includes the uncompressed length. We won't decompress more than that. (And we'll reject if the decompressed result isn't exactly that length.) That length, in turn, must be under the existing limit for uncompressed certificates or we'll reject without even trying.

(The Security Considerations part of the spec has some text about this.)

--

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/18ea8a44-cd00-41fa-83c8-19db2ccd1472%40chromium.org.

[Mike West]

LGTM2. This is a positive change and is well thought-out, and I agree with davidben@'s read of the IETF minutes. Martin replied positively on https://github.com/mozilla/standards-positions/issues/96 as well, which is a solid indication.

Thanks!

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBYyBNVR1hqorbd1Th_6_OdvCy7EpnvCZjrECjnb%3DcK9A%40mail.gmail.com.

[Chris Harrelson]

LGTM3

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/CAKXHy%3DeMUXCyR5eX9UOD9YQMEE%2Btz__M1Gmw6Qyh34AXo47fzQ%40mail.gmail.com.