Re: [TLS] TLS 1.3 draft 22 middlebox interaction

[Yuhong Bao <[e-mail]>]

I was talking about that arms race not that long ago.

________________________________________
From: TLS <[e-mail]> on behalf of David Benjamin <[e-mail]>
Sent: Friday, December 1, 2017 8:34:53 AM
To: Eric Rescorla
Cc: [e-mail]
Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction

On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <[e-mail]<mailto:[e-mail]>> wrote:
I want to provide some feedback that might be useful to the TLS WG:  Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org<http://tls13.crypto.mozilla.org> is triggering an interesting failure in at least one middlebox.

The middlebox in question supports TLS 1.3, but only drafts 18 through 21.  The FF Nightly ClientHello supported_versions extension advertises support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then interprets as only advertising support for TLS 1.2, ignoring the 0x7f16 as if it is a "grease" value.  The middlebox only perfoms protocol checks and does not actually modify anything - the session completes without any issues, which shows that the draft 22 middlebox measures are effective.  FF Nightly then starts a resumed TLS 1.3 (draft 22) session that includes 0-RTT early data.  The middlebox performs a protocol check on the ClientHello and determines that the client is trying to negotiate TLS 1.2 (per the logic of the first session).  Shortly afterwards the 0-RTT AppData record arrives, which then triggers a protocol error in the middlebox.   "D.3. 0-RTT backwards compatibility" of the draft 22 specification describes the problem, but in the context of "older server" being "only supports up to TLS 1.2".  This particular middlebox can also be thought of as "older" because it only supports TLS 1.3 drafts 18 through 21.

Obviously the middlebox will soon have support for draft 22, but it does raise some questions:

1. I understand that some of these transition effects will go away as soon as draft support is replaced with actual 0x0304 support, but were 0-RTT sessions used in the recent TLS 1.3 middlebox resiliency experiments?  The scenario above shows that some middleboxes might (by luck?) not break full TLS 1.3 sessions, but those same middleboxes might fail with subsequent 0-RTT early data.

We haven't been testing that. I do expect to see some 0-RTT bustage, but falling back to a full handshake at that point isn't a security issue, and so can be handled in the conventional reconnect way. We (Firefox) also are looking at testing for middlebox compat explicitly and turning off features like 0-RTT and TFO (which we already see problems with) if needed.


2. Should middleboxes that understand the supported_versions extension get out of the loop immediately (as in ignore traffic after ClientHello) when it sees 0x7fNN, where NN is larger than the highest draft version supported by the middlebox?  How would that be different from other "grease" values?   I understand that this might just be a temporary measure until 0x7fXX goes away (hopefully soon!).

First, they shouldn't look at #s. Second, it depends what kind if middlebox you are. If you're a protocol enforcing middlebox (ugh, these shouldn't exist) you should get out of the way. If you're a MITM device you should just negotiate a lower version.


3. Is there a plan for phasing out draft support once TLS 1.3 is finalized as RFC?  Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but what should a middlebox do if 0x7fxx is seen post RFC?

I would expect people to just signal the RFC version relatively shortly after RFC. That's what we (Firefox) plans to do.

To answer your question more directly, as EKR noted above, post-RFC and pre-RFC, middleboxes should not behave differently for 0x0304, 0x7fxx, 0x1234, or 0x0305. If you did not terminate the connection, you don't get to parse variant-dependent fields.

Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign to change everything past the ServerHello again. Or perhaps we'll design a new cipher suite or extension that changes things. New capabilities may be signaled by the client anywhere in the ClientHello. Recall that past TLS 1.2 extensions have injected new messages in the handshake and changed the format of the Certificate message. Adding ECDHE and PSK cipher suites changed how ClientKeyExchange and ServerKeyExchange worked. Earlier drafts of TLS 1.3 completely changed the handshake.

I started writing some text on version invariants to make these rules clearer. They were the assumed rules in TLS 1.2, but draft-22 reflects that the network did not honor them. I'll finish that up and make a PR. I do not believe writing this in text will be sufficient, but it is evidently necessary.

TLS's versioning invariants are quite simple: if you are not terminating the TLS connection (i.e. the ClientHello was not produced by you), you MUST NOT process any message beyond the ClientHello. If you produced the ClientHello, you can reasonably expect to understand the response and can act as an endpoint does.

Any middleware violating this invariant is non-compliant and at risk of breaking as endpoints and the protocol evolve. Alas, this was insufficiently GREASEd from SSL 3.0 through TLS 1.2, so we had to grandfather in existing violations via draft 22.

Future violations, however, continue to be non-compliant and you should expect them to break, and quite rapidly as draft-22 shows we need more ideas in the vein of GREASE.

David