DPI, admittedly, is an expensive process that slows down traffic. DPI is even more expensive on a protocol such as TLS where the record headers aren't always in the same place in every packet. DPI is usually off by default on most firewalls.
The problem you are more likely to encounter are TLS interception proxies that end up using only TLSv1.0 to authenticate a connection. Having this controlled by a TLS extension would at least give the client a modicum of control. (Oops, connection failed, let's try it again with a 3.1-compatible header.) Also, having the "major" version number be 4, should indicate to these DPI engines that this is a new version of TLS, and should use new code or be ignored. Heck, the version in the handshake should be indicative of this. I think the philosophy some people are going with, if we're going to break backwards compatibility, let's do it big time, so that we only have to do it once, and not make everyone play continuous catchup. -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." > On Nov 18, 2015, at 4:09 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > > >> On 18 Nov 2015, at 3:32 AM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: >> >> Eric Rescorla <e...@rtfm.com> writes: >> >>> The concern here is backward compatibility with inspection middleboxes which >>> expect the length field to be in a particular place. >> >> Given that the rest of TLS 1.3 is going to break compatibility with pretty >> much everything everywhere, I can't see this as a big concern, may as well >> fix >> it at the same time as everything else is being changed. > > Stateful firewalls tend to pass only what they understand. They use some > measures to avoid tunneling and passing things that are not HTTPS over TCP > port 443. > > To achieve this, they run sanity checks on the traffic. They try to strike a > balance between not getting circumvented and not dropping legitimate traffic. > Sometimes they get it wrong. Sometimes they block legitimate but surprising > stuff. As an example from 15 years ago, when Mac OS 9.2 came out, it sent > data on the third packet of TCP (the ACK - last of the handshake packets). > This is allowed by RFC, but was not done by any other platform. This failed > the sanity checks of some firewalls, causing that traffic to be blocked. Two > results of this event: we fixed our firewalls, but nobody (including Apple) > does that anymore. > > A sanity check on TLS might involve validating 5-byte record headers with > sane length and version fields. A firewall might be out there that verifies > this. This is the kind of thing that might be missed in testing, and we’ll > only find out when some brave soul deploys TLS 1.3 in Chrome only to find out > that it is blocked in 3% of the Internet. > > Yoav > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
