Re: [TLS] TLS 1.3 draft 22 middlebox interaction

On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <r@nerd.ninja> 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.

-Ekr

>
>
>
> --Roelof
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>