Re: [TLS] Forged RST (was: About encrypting SNI)

[Yoav Nir <[e-mail]>]

On Apr 17, 2014, at 1:54 AM, Alyssa Rowan <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 16/04/2014 21:34, Jacob Appelbaum wrote:
> 
>> […] and that often results in say, a forged TCP RST packet.
> 
> Which, incidentally, we should consider something to address,
> especially if we do indeed have a bakeoff of some form for a fancier
> TLSv2.0.
> 
> NSA calls this technique QUANTUMSKY (one of their less catchy cover
> names) but it's been around for aeons (most famously in the Chinese
> 'Golden Shield'): any man-on-the-side can simply RST your TCP
> connections if they don't like the way they smell, and this is (by
> far) the cheapest and easiest way for a nation state adversary (or
> malicious coffee shop WiFi) to selectively disrupt, or censor,
> communications.
> 
> Could we plug that hole in a future version of TLS?

We’re at the wrong layer to fix an attack against TCP.  The right place to protect TCP is either in TCP itself, or by using IPsec.

> The obvious way involves UDP, and baking transport control (and
> multiplexing?) inside that layer, within the encryption. In fact it's
> so obvious, everyone likes to cook up their own recipe: lots of people
> have done something in that general area already in different ways,
> and discovered interesting things about it (Google's QUIC being one
> notable recent foray into the field).

Those who won’t use TCP are doomed to re-create it. To get a UDP-based protocol to replace TCP for the web you’d need all of reliable delivery through (selective?) retransmissions, bandwidth detection, replay protection, a whole lot of things that took the transport community years to get right. Yes, there have been many attempts, but there’s a reason TCP is still the protocol everyone uses for pretty much any type of bulk transfer. And this is before we even begin to talk about middleboxes dropping unrecognized UDP services.

> UDP is also notably better for
> connections through NAT and suchlike. (I've even done my own
> experiments in that general direction, although delicious and moist as
> they seem to be, they're simply experiments and I'm not yet ready to
> serve them to guests, let alone strangers!)

UDP is connectionless. As such, NAT devices don’t know when it’s done. So NAT mappings need to linger a lot longer after the last packet. TCP works better with NAT.

> It also results in something that probably looks more like DTLS than
> anything we have now, or something even stranger, or like nothing
> anyone can recognise.
> 
> It may, or very well may not, be a good idea (gleefully gratuitously
> rampant layering violation/wheel reinvention vs. avoiding unnecessary
> insecure layers vulnerable to a real, deployed attack/square wheel),
> but I'd be interested (with no particular hurry) if anyone had had any
> thoughts in that direction.

It would require an explanation about why this new wheel would be better than TCP in IPsec.

Yoav