Re: [TLS] TLS 1.3 draft 22 middlebox interaction

[David Benjamin <[e-mail]>]

On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla <[e-mail]> wrote:

> On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <[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
>> 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