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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
