Subject: [TLS] TLS 1.3 draft 22 middlebox interaction

From: R du Toit <[email-masked]>
Date: Fri, 01 Dec 2017 09:47:45 -0500

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" bei
 ng "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.

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

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?

--Roelof

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Dec 2017 07:18:02 -0800

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

-Ekr

>
>
>
> --Roelof
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 01 Dec 2017 16:34:53 +0000

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

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

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

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 2 Dec 2017 01:51:13 +0000

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

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

On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <[email-masked]<mailto:[email-masked]>> 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.

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.

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.

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

---

From: Hanno Böck <[email-masked]>
Date: Sat, 2 Dec 2017 15:55:25 +0100

On Fri, 01 Dec 2017 09:47:45 -0500
R du Toit <[email-masked]> wrote:

> 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),

Sorry, can you please name names here? In what universe does this make
any sense?

The middlebox shouldn't look at specific TLS versions. And it certainly
shouldn't look at specific TLS 1.3 drafts. It should just leave the
traffic alone.
Doing anything of the form "we'll accept traffic of TLS version X, but
not of any version unknown to us" is certain to cause breakage in the
future. Whoever built this is harming the Internet, full stop.

I really don't understand why there is such intransparency over this
issue. Why can't we at least make clear who are the companies
responsible for this nonsense?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 Dec 2017 16:46:24 +0000

➢ I really don't understand why there is such intransparency over this
    issue. Why can't we at least make clear who are the companies
    responsible for this nonsense?
    
Adam Langley posted something to this list awhile back, but I can’t find it, sorry.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 3 Dec 2017 17:55:52 +0200

On Fri, Dec 01, 2017 at 09:47:45AM -0500, R du Toit wrote:
> Firefox Nightly TLS 1.3 (draft 22) sessions to
> tls13.crypto.mozilla.org is triggering an interesting failure in at
> least one middlebox.
>  

Some rules are:

If any of these happens, you are dealing with Undefined Behavior
w.r.t. what is implemented, and the remainder of handshake can not be
parsed, because it may have been altered in arbitrary ways.

- The first client message is not of type 1
- The ClientVersion is not "SSL 3.x" (first byte in CH is not 3).
- The first server message is not of type 2.
- The ServerVersion is not known.
- Any unknown extension is accepted by the server.
- Unknown value is accepted in server extension.

For example about just how devastating unknown extension can be,
consider what the supported_versions from TLS 1.3-draft22 does...

However, note that none of the above actually covers 0-RTT. This is
because no earlier version envisioned anything like 0-RTT.

In certain environments, it might make sense to require ClientHello to
be parseable (e.g., for non-standard end-to-path signaling). There is
much less reaso to try to parse ServerHello.

> 1. [...]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.

As noted elsewhere, 0-RTT failures are much less severe than full
handshake failure.

Dropping 0-RTT is not a security problem (in fact, might just be the
opposite). It is at worst minor performance problem. But downgrading
versions absolutely is a security problem.

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

What are you doing trying to parse ClientHello? And more importantly,
what are you doing trying to parse anything after that?

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

Well, speaking of the library I maintain, I do not have plans on
dropping support for drafts. This includes support for draft-18 (e.g.
Firefox 52 ESR).

However, once TLS 1.3 hits RFC-ed-q, I plan on adding "draft-255"
(TLS 1.3 final; 0x0304) and hardcoding FLAGS0_ENABLE_TLS13 to true.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Mon, 04 Dec 2017 19:46:10 +0100

> Adam Langley posted something to this list awhile back, but I can’t find it,
 
I haven't seen him mention any names either
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Dec 2017 18:52:59 +0000

>    I haven't seen him mention any names either
 
I wasn’t clear.  He posted that they weren’t going to post names.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 04 Dec 2017 19:57:49 +0100

On Monday, 4 December 2017 19:52:59 CET Salz, Rich wrote:
> >   > Adam Langley posted something to this list awhile back, but I can’t
> >   > find it sorry.
> >

oh, then that does match my recollection

but I'm similarly disappointed about the opaqueness of the whole process

---

From: R du Toit <[email-masked]>
Date: Tue, 05 Dec 2017 20:00:53 -0500

Thank you for the thoughtful responses so far.  I have been working in the middlebox arena for more than 20 years, and I am also concerned about the state of certain implementations.  I would like to think that the TLS stack that my team and I maintain have no serious security flaws, but vulnerabilities in TLS stacks have shown that even people with the best of intentions get things wrong at times.  Security conscious middlebox vendors would certainly like to fix their bugs, while at the same time improving interoperability with TLS 1.3.  The middlebox in my original post, for example, has already fixed the 0-RTT draft-22 interop issue.

Anyway, that is my way of saying that there are many people like myself following the TLS WG email threads, and we all want to help make TLS a success for consumers and enterprises.  It would be good if middlebox vendors could actually participate in experiments - especially to iron out some of the corner cases.

I also want to reply to some specific comments:

>> If you're a protocol enforcing middlebox (ugh, these shouldn't exist) you should get out of the way.

Middleboxes often need to decide if they want to be a MITM or not on a per-session basis.  This requires parsing the CH as if the middlebox is a TLS server.  It should always be safe to parse the CH, but while the middlebox is in this “server phase” it might receive unexpected data before TLS versions have been negotiated, or before the middlebox has even decided to terminate the TLS session.  I agree that the middlebox should not try to enforce protocol checks beyond what is certain.  Up until TLS 1.3, any record that follows a CH before SH is received was a protocol error.  It was also a possible indication of attack.  For example, many simple attack scripts looking to exploit Heartbleed would send a heartbeat record immediately after the CH, without waiting for a reply from the server.  I agree that the right place to fix Heartbleed is on the server, however there are still vulnerable servers out there, and this sort of protocol validation does in fact help.

>> Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign to change everything past the ServerHello again.

The questions here were actually with regards to 0-RTT data, which occurs before the ServerHello.  If the middlebox supports only TLS 1.2, and it terminates TLS, is it correct for the middlebox to break the connection when it sees 0-RTT data?  Will this be counted as a middlebox “causing” a failure, because it does not seem like there is another option for the middlebox if it is terminating the TLS session.

>> If any of these happens, you are dealing with Undefined Behavior ...

Indeed, and I can imagine other fields being overloaded.  Who would have thought at the time that cipher-suites would one day be used as backwards compatible signals that can propagate through poorly implemented middleboxes; "random" bytes already have special meaning; unknown record types were used in attacks; etc.

>> However, note that none of the above actually covers 0-RTT. This is because no earlier version envisioned anything like 0-RTT.

Exactly!

--Roelof