Re: [TLS] TLS 1.3 draft 22 middlebox interaction

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

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