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 

[je...@somethingsimilar.com]

Hey, I had the need to add names for these ciphersuites to howsmyssl.com. I gave them bogus names as described at https://github.com/jmhodges/howsmyssl/pull/141/files#diff-db22e7b08c329fd557a1e19926953ff3R363

Y'all come up with other names for these ciphersuites? Haven't found them written down, yet.

> Is this a joke? This sounds like a jokeNo, but it is a very convenient acronym.

[David Benjamin]

The draft just calls them "GREASE values". They don't have names because they're not really cipher suites. :-)

They're just a bunch of permanently unassigned code points to get implementations used to ignoring unknown things before they ship. (Apparently this works! We've already prevented version and curve intolerance in an early TLS 1.3 implementation.) Our code doesn't have #defines or SSL_CIPHER structs for them or anything. The serialization code just picks a value and adds it in before writing out the cipher list.

We'll see what kinds of amusements the IETF is willing to do, but I would not want them individually named in the IANA registry. It seems to be common for TLS implementations in pattern-matched languages to define a type for each registry and transcribe the table, forgetting to handle the unassigned case correctly. I've even seen one pattern match a private use block, which suggests it was just transcribed without thinking.

The ideal case would be if they weren't in the table at all and just tacked on a prose note somewhere: "The following values are left permanently unassigned [citation]: 0x0a0a, 0x1a1a, ..."

(I'm currently waiting for the WG adoption call to resolve and then I'll go about proposing this and other changes in my queue.)

[Alex Gaynor]

I suspect from a UI perspective, you want to do the same thing you do with the FALLBACK_SCSV ciphersuite, which appears to be "ignore it in the UI".

Alex

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

--

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[Jeff Hodges]

Cool, thanks.

Sorry about replying to all on this thread. The Groups UI had convinced me I was sending only to David.

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