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

Alyssa Rowan <akr@akr.io> Wed, 16 April 2014 22:54 UTC

Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0291A0382 for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 15:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmIxYiKmAvQx for <tls@ietfa.amsl.com>; Wed, 16 Apr 2014 15:54:42 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 565E71A02E8 for <tls@ietf.org>; Wed, 16 Apr 2014 15:54:42 -0700 (PDT)
Message-ID: <534F0A33.9070408@akr.io>
Date: Wed, 16 Apr 2014 23:54:43 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: tls@ietf.org
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <D2CB0B72-A548-414C-A926-A9AA45B962DA@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <CACsn0cmusUc3Rsb2Wof+dn0PEg3P0bPC3ZdJ75b9kkZ5LDGu_A@mail.gmail.com> <534DB18A.4060408@mit.edu> <m2ppkhl08c.fsf@usma1mc-0csx92.kendall.corp.akamai.com> <CAFggDF13=bKS3_kRz_uh-6y71TQ9O4v1e3+xs3fiM4YZwjAULA@mail.gmail.com> <CALCETrU-w=yon9TVzbvGSbznEgThxzUkzy4Yeu+CBfSp7Zk2hw@mail.gmail.com> <CAFggDF3i1ku++GWMp=03aL3ogpHO_Fg9qJ3daZuLN4SH5Fcj8g@mail.gmail.com>
In-Reply-To: <CAFggDF3i1ku++GWMp=03aL3ogpHO_Fg9qJ3daZuLN4SH5Fcj8g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R11rfMA5LDrKqMkYiYxaRuR5ROU
Subject: [TLS] Forged RST (was: About encrypting SNI)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 22:54:43 -0000

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

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

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.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTTwoyAAoJEOyEjtkWi2t6/eoQAKlvRCFsqyZI3pwWG1929+5u
zn23iFhpZBo7Yna9ATUpdGGXUAGr6r3SC2gemyezNlyRsKWG7HPWq1dBbseT+Ubp
fRVsCS2qsCty6v7ZB/uMxs9uxEucRudZN6ibJ0J9IoC22TsC8O/2NuXr5uuvVahd
+Dk8k2dgXmf9NFXgjLmweneX+lI7rjVctSfJM5OmkJ9sz5GKzpxkaR0k7rwLHu23
L1sKyUGOJjam7LsA8wGOgQyCx3wCfqcFwtVECn5P+xpLaOfFznulvD56aXm+MGNO
nM4OVAzErrqtYNJJL48YgR3XCrQ+6fU1Gu1A3KNS2uCzrnJO9nTBLS3uR4FEvxLL
XrLxeol8+Csh+QQjvX3x/sGDZBX3jUhoNchqUP+u5Vl/+ca6T85k1A5GNI5tY5yG
kMec1vLcpsVTYvi9CDV8HjhTnCU5tsueyVkpNWW141UtbNF8VxdGnqSqj7VBysPh
cAAc4AOb2GuD7c5RdYsUvp3vEeuUgnewkOLDLW2W+uBbLHh3hDB4egy3B2HlxGFN
/jlK2ZXgba4pcReI9PU7c4QSQjpdFB213B1WLt3rGen9aUlTAr1HESbMt0PIxpyQ
hEu7uYIaxjj/n/j/R1A2FiIhkFY9K07WqXSIjAdPRQU2cAiyljBZ76Yg9tQwYKXj
EzCJFwn2UX1OzVhmhaG6
=aDNf
-----END PGP SIGNATURE-----