Re: [TLS] Forged RST

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/17/2014 01:58 PM, Erik Nygren wrote:
> Some of this ties directly into the tcpcrypt discussions.  

Yes, noting though that the TCP encryption/tcpcrypt work
is at a far earlier stage than TLS. (Its good stuff though,
or will be, I hope.)

> It may be worth
> having a discussion somewhere in the IETF on which protections belong in

I'd quibble with "belong" there. I think to some extent our
(the IETF, not the TLS WG) job is to define protocols that get
implemented so that whoever is deploying can turn on the
security they want. Its a big old Internet out there after all,
and I'm not sure our best guess at which-layer-does-what-best
is likely to be right for all time for all places.

> which layers and how we make sure they can compose safely.  

That part I definitely do agree with. And with having a more
general discussion, which I'd hope will feed into our nascent
plans to add to BCP 72 in a while.

This is not the right list for that discussion of course, but
if you (or someone) wanted to write a draft and get a discussion
going on saag that would be good. (I suspect that might be
more useful when the TLS and tcpcrypt discussions are a little
further along though, maybe in/after the summer.)

Cheers,
S.

> It may be that
> protecting the handshake from passive attacks also belongs in the tcp
> layer.  See my previous post on this topic:
>            http://www.ietf.org/mail-archive/web/tls/current/msg11693.html
> 
>       Erik
> On Apr 17, 2014 4:27 AM, "Yoav Nir" <[e-mail]> wrote:
> 
>>
>> 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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>