Intent to Implement and Ship: GREASE for TLS

[David Benjamin]

Contact emails

davi...@chromium.org

Spec

https://tools.ietf.org/html/draft-davidben-tls-grease-01

Summary

The TLS protocol provides several extension “joints” which we exercise on occasion to add new features. These typically are lists of opaque 16-bit code points (such as cipher suites) that the client offers and the server selects. For these extension points to work, servers must correctly ignore unknown values.

However, bugs may cause a server to reject unknown values. These broken servers will interoperate with existing clients, so the mistake may spread through the ecosystem unnoticed.  Later, when new values are defined, updated clients will discover that the joint has rusted shut and that the new values cannot be deployed without interoperability failures.

(For those more familiar with HTTP or JS, imagine if sites broke on unexpected HTTP headers or JS attributes and we didn’t add new ones often enough to prevent this.)

GREASE (Generate Random Extensions And Sustain Extensibility) is a proposal to reserves some currently unused values for clients to advertise at random. Correct server implementations will ignore these values and interoperate. Servers that do not tolerate unknown values will fail to interoperate with existing clients, revealing the mistake before it is widespread.

We intend to apply GREASE to TLS cipher suites, extensions, and ECDH curves, hopefully expanding to other fields in the future.

Motivation

There is a baseline compatibility risk when making any TLS change that we will discover one of these intolerances. This is particularly problematic for joints which we exercise very rarely. GREASE’s goal is to decrease this baseline risk for future changes by keeping our joints well-oiled.

Interoperability and Compatibility Risk

Each of the categories being GREASEd have been added to relatively recently, so we expect the ecosystem is currently tolerant to new values. Rather we hope to reduce compatibility risk in the future with this change.

We can always safely remove this if needed. GREASE values don’t do anything, so, barring some creatively catastrophic server bugs, no server can depend on their presence.

Finally, we are burning 16 code points, but 16 is a much much smaller number than 65536.

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/648327

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

Is this a joke? This sounds like a joke

No, but it is a very convenient acronym.

[Harald Alvestrand]

I like this :-)

What's the status of the IETF document (which still has the values as TBD)?

Note on the IETF document:

 [[TODO: How do I write IANA instructions to reserve all ALPN
   identifiers that begin with "ignore/"?  Perhaps it would be better to
   reserve a concrete handful of identifiers instead.]]

The way to do it is likely to say "This document updates the registration procedures in <whateverdocumentthatis> to prohibit registration of values starting with "ignore/"".

--
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.

[David Benjamin]

On Mon, Sep 19, 2016 at 3:10 PM Harald Alvestrand <h...@google.com> wrote:

I like this :-)

What's the status of the IETF document (which still has the values as TBD)?

The -00 doc actually picked some numbers, and then I was advised to put TBD in there and write things like "{TBD} {0x0A,0x0A}" in the table. Those are the values I'm planning on using. (I'd like the values to be sparse and it's convenient for the same pattern of values to be burned in each registry, so I picked a pattern that comfortably missed all the ranges people are allocating things in.)

There's been some mailing list chatter on tls@ (subjects "Keeping TLS extension points working" and "draft-davidben-tls-grease-01"). I'm actually not sure what the next step is spec-wise. I'll poke people. I figure these can proceed basically in parallel since these numbers literally don't do anything and 2^16 is a large number. Unlike the HTTP header or JS API world, the numbers themselves are not significant.

 

Note on the IETF document:

 [[TODO: How do I write IANA instructions to reserve all ALPN
   identifiers that begin with "ignore/"?  Perhaps it would be better to
   reserve a concrete handful of identifiers instead.]]

The way to do it is likely to say "This document updates the registration procedures in <whateverdocumentthatis> to prohibit registration of values starting with "ignore/"".

Mostly I was wondering how that would translate here:

http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

I guess IANA could just add a sentence to the bottom? (I wasn't planning on doing anything to ALPN for this iteration. I figure we can do that in a second or third round. Unlike the numbers, ALPN strings have some vague human-readable significance.)

 

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

[Mike West]

This approach LGTM. It promises to avoid some of the compatibility/bake-in issues that we've experienced with TLS <1.2 implementations, and I think the experiment is likely to either ensure that future migrations work well, or ensure that we discover blocking issues early. Either of those outcome seems significantly better than status quo.

Nice work! :)

-mike

--
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/CAF8qwaA%3D-qy7T%2BMz5OwdZHw75sHUGK9fsMcMZHnhKUxaS78_0w%40mail.gmail.com.

[Chris Harrelson]

LGTM1

--
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.

[Jeffrey Yasskin]

Are vendors likely to hardcode the GREASEy values, and continue to
break when confronted with future extensions?

[Adam Langley]

On Wed, Sep 21, 2016 at 2:51 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

Are vendors likely to hardcode the GREASEy values, and continue to
break when confronted with future extensions?

We have to hope that doing the right thing (ignoring unknown values) is the easier option :)

(Fundamentally we can't stop someone determined to be dumb. But if they had to think and chose to do the wrong thing then we did our best.)

Cheers

AGL 

[Philip Jägenstedt]

LGTM2

[Harald Alvestrand]

(If you're not interested in IETF mechanics, you can stop reading now)

The natural next step for a small item like this is probably to ask the WG chairs and the AD if they're willing to send this to the IESG as "AD-sponsored, has been discussed in WG, but is not a WG product". If all agree, it's a 4-week Last Call.

The change in the IANA page would be to change the "reference" from "RFC7301" to "RFC 7301, <RFC of this doc>". Given that IANA instructions want IESG blessing, that probably means intended status of this doc should be BCP, not Informational.

If everyone likes it, this should be easy; if not, there will be discussions......

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

[David Benjamin]

Thanks! I mailed the WG chairs a couple days ago for early code point allocation. EKR (TLS 1.3 editor) recommended that we do that and then queue this document behind TLS 1.3 so it can be updated with TLS 1.3 registries once the WG has sorted 1.3 out.

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

[Joe Mason]

On Mon, Sep 19, 2016 at 3:10 PM, 'Harald Alvestrand' via Security-dev <securi...@chromium.org> wrote:

 [[TODO: How do I write IANA instructions to reserve all ALPN

   identifiers that begin with "ignore/"?  Perhaps it would be better to
   reserve a concrete handful of identifiers instead.]]

Seems like reserving the pattern "ignore/*" doesn't follow, "These values were allocated sparsely to discourage server implementations from conditioning on them." In particular I could easily see someone investigating connection failures, noticing "ignore/something" fouling up their logs, interpreting the word "ignore" itself as significant, and jumping to the conclusion that they they should blacklist "ignore/*" rather than all unknown values.

[Jochen Eisinger]

lgtm3

[David Benjamin]

Good point. I don't want to spend too much effort on special-case discouragement (as Adam notes, there's nothing we can do if a server is determined to be dumb), but I agree this one is probably too tempting. I'll switch it to a different pattern. Maybe just two-byte values that correspond exactly to the other GREASE numbers. They don't actually need to be human-readable...

(We're not going to try to apply GREASE to ALPN for this Intent either way, largely because "ignore/*" thing was so different from the others.)

David