On 12/1/15 10:12 AM, Yoav Nir wrote: >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <ja...@appelbaum.net> wrote: >> On 12/1/15, Viktor Dukhovni <ietf-d...@dukhovni.org> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
