Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Yoav Nir <[e-mail]>]

> On 1 Dec 2015, at 4:55 PM, Bryan A Ford <[e-mail]> wrote:
> 
> On 12/1/15 10:12 AM, Yoav Nir wrote:
>>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <[e-mail]> wrote:
>>> On 12/1/15, Viktor Dukhovni <[e-mail]> wrote:
>>>>   * Interoperable in the field with various capital-intensive
>>>>     middle boxen.
>>> 
>>> Which would those be? And what is the definition of capital-intensive
>>> for those watching on the sidelines?
>> 
>> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on protocols to make sure that the stuff going over TCP port 443 is really HTTPS rather than an attempt at tunneling. There are some attacks such the the code that protects against them needs to follow TLS record sizes. For the most part these are not-so-interesting attacks, causing certain versions of certain browsers to hang, and they are expensive for the firewall to protect against, so for the most part these protections are turned off. But it’s not everywhere.
> 
> Certainly there are middleboxes that try to use traffic analysis to
> detect attempts at tunneling - but the fact that the traffic is HTTPS
> doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation
> does exactly that (and is sometimes used for exactly that purpose).
> 
> Regardless, does the IETF really want to be in the business of making
> sure that protocols like TLS are designed to avoid making life
> inconvenient for developers of Great Firewalls of whatever type?

Convenience has nothing to do with it. The next version of every firewall out there is going to support TLS 1.3. If TLS 1.3 means that the middlebox cannot parse the record lengths, then the next version of the middlebox will give the administrator the option of blocking TLS 1.3 or disabling the processing that requires following record lengths.  The issue is with all older version middleboxes that are out there. They don’t get updated nearly as often as we vendors would like. 

And the IETF is in the business of developing protocols that work and can be deployed. For counter-examples look at SCTP. It is not deployed because middleboxes (mostly NAT devices in this case) didn’t know what to do with it. It’s fairly simple to NAT SCTP, but the old middleboxes didn’t know how. Newer middleboxes still mostly don’t know how to NAT SCTP. Why? Because nobody’s using SCTP, so why bother? There are a dozen other features that customers actually want that need to be developed.

>> If enough middleboxes block TLS 1.3, the browsers will implement a downgrade dance. If they do that, attackers will be able to exploit the downgrade dance. I don’t think the net effect is better security. We’d be far better off writing a separate document on how to use the padding feature that is already in 1.3 to mitigate traffic analysis without actually flooding your Internet connection. Splitting records and padding a few can be more effective than masking the length bits.
> 
> Browsers have to implement a downgrade dance anyway to be able to talk
> with web servers that don't support TLS 1.3.  TLS 1.3 already changes
> plenty of things that middleboxes "might" not like; absent concrete
> evidence of major incompatibilities specifically caused by the proposed
> change, I don't see why we should avoid changing one more bit of the
> protocol that middlebrowsers "might" not like.

That is not what a downgrade dance is. The normal way of version negotiation goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) OK, I choose 1.2.

By the end of the handshake both of the above messages enter the calculation of the Finished message so it’s fine.

A downgrade dance goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) RST
Client: (old server that didn’t implement version negotiation right. Sigh) I support TLS 1.1, 1.2.
Server: OK, I choose 1.2.

In this case only the last two messages get into the Finished message. As a result, an attacker (whether on-path or not) can easily induce the downgrade dance by sending a RST, but it cannot induce version negotiation down to 1.2. Browsers are just now getting rid of the downgrade dance they had for 1.2. It would be a shame to have to re-introduce it.

Yoav