3 ms·

I personally believe stop breaking these middleboxes is a necessary evil/compromise to make TLSv1.3 to be universally accepted. The net gain is a huge positive.

I personally believe stop breaking these middleboxes is a necessary evil/compromise to make TLSv1.3 to be universally accepted. The net gain is a huge positive. > Breaking them (and thus effectively forcing them out of the way) would have been the better approach. This is exactly what the security people are going to do after TLSv1.3 is introduced. Google Chrome is going to implement the so-called GREASE protocol (https://tools.ietf.org/html/draft-ietf-tls-grease-01 https://tools.ietf.org/html/draft-ietf-tls-grease-01), which actively tries to negotiate a connection with random, non-existent, but standard-compliant values in various fields of the protocol, to actively break the (future) broken middleboxes early on. Revenge time.

dwheeler 8y ago
I think GREASE has an excellent chance of long-term success, and if it works, other protocol implementations should start doing the same thing. Actively requiring implementations to support future compatibility looks like an excellent plan. In case people are curious what TLS 1.3 did to support broken middleboxes, a lot of information is in "D.4. Middlebox Compatibility Mode". Here's the text: > Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake... I think working around it in the short term (so that TLS 1.3 can start improving our protections NOW), and separately getting middleboxes to upgrade over a longer period of time, is a good plan.