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

[Bryan A Ford <[e-mail]>]

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?

> 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.

B