On Fri, Dec 01, 2017 at 09:47:45AM -0500, R du Toit 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. > > Obviously the middlebox will soon have support for draft 22, but it > does raise some questions:
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? > 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? 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
