[TLS] TLS 1.3 draft 22 middlebox interaction

[R du Toit <[e-mail]>]

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