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

Jacob Appelbaum <jacob@appelbaum.net> Thu, 03 December 2015 03:38 UTC

Return-Path: <jacob@appelbaum.net>
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 AF45F1A0126 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 19:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
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 EGpnBNNmHnvW for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 19:38:41 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A781A0024 for <tls@ietf.org>; Wed, 2 Dec 2015 19:38:41 -0800 (PST)
Received: by igcto18 with SMTP id to18so3273476igc.0 for <tls@ietf.org>; Wed, 02 Dec 2015 19:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u85cvTrVNmAeFdbwLxtlbim8XSsupzSZ4XlZP7+rzKA=; b=DgQZ/4QrFf99mZMy38SZiVGwXkhLr/vcy9RdWoRaS+t4Glj7VTRFjsUbix1dZ/j9TP mu4qdW9UoUnaEYh/2GAVe9EJqwnUtFm/M6ZiIc5YX2hU/33VCqwdy/febJKCzc2ZGcbt XQo1EeiybGt4JgeXGjqekgpGZbhFOOherPUu47sCKQAR/jTGV718Ex3kh2RQa30q9CAS MzXGYyiqso1kaS7GwkTmV0qh5br79z2nLvFt0uJ5aD5P40ZCGFostFf+dPpDonuklj82 hxLUSgSf4hGzX16ewG3S6voA7fYw53jHDCOiJMbauqLOkk2n5+emHmuF6b+OlDz3cQFz KOvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u85cvTrVNmAeFdbwLxtlbim8XSsupzSZ4XlZP7+rzKA=; b=WXOmubgkLGZi0OAbUcOZK3rufKf60qVsR9/VZ4bsi/xeEWe8eT5nmTXSleQz+SS3+W NBPTwK0K6ntR2vfP8WF05hXgH9AulC+at4D9RD+O34m3opmoIjPW7TqoRkS4vk8IMjcf Kt9Td/5XmTn08Lzh1huHLXb9/+PjZD3bUGxgR/viUfyLISR4NB1EimvlajVo9uykYkXV Gl9hewhPKodVrw7T4nlf+4seTxT0LnBewasGoWuPxVVISoGCNC1Bml1UZSkorx2ZYhPs UkNXePI2XbqzmkD2uDdFLfspBikBnm3uqdUsqjKzRRtDDqDsatCvNatUc3L+unYd9Xdg xcaQ==
X-Gm-Message-State: ALoCoQlbCrBTLfynlYw4cVsJReCbt5VDvkD9CQrUT+ojjECSHU/2zzQ/WKUQhah/o0rBlXAXiTVL
MIME-Version: 1.0
X-Received: by 10.50.49.109 with SMTP id t13mr36611516ign.89.1449113920501; Wed, 02 Dec 2015 19:38:40 -0800 (PST)
Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 19:38:39 -0800 (PST)
X-Originating-IP: [46.188.10.23]
In-Reply-To: <201512021513.49894.davemgarrett@gmail.com>
References: <CAFggDF3HP5u0YP0UP_HrrZnrTnzc-CD1EG0grZBcb5sB7A2fAA@mail.gmail.com> <CAFggDF0D3Rgav-4xg-11u0igMyMXvAWT+JNt2r1xyQnpvm08Qw@mail.gmail.com> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com>
Date: Thu, 03 Dec 2015 03:38:39 +0000
Message-ID: <CAFggDF3gg-7Gy8JkfDbK4KppwvjbPju6yzVH1aRe=4kJYE65Uw@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/941VXyYzkGB_hmhjq4zoL791Pa8>
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Dec 2015 03:38:42 -0000

On 12/2/15, Dave Garrett <davemgarrett@gmail.com> wrote:
> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>> Encrypted SNI doesn't give you the kind of protection you think that it
>> does.  We (me and a colleague) did a pretty thorough analysis that showed
>> this.  It was not a conclusion we expected, or wanted, to reach.   It was
>> presented at the TLS Interim before the IETF in Toronto.  Slides should be
>> online.  (For example, the adversary will know the IP address or might not
>> care about false positives, etc.)
>
> URL from Rich's previous email citing this:
> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view
>

I've read these slides. I'm... at a bit of a loss. The entire slide
deck seems so flippant as to be not worth addressing. It just doesn't
even pass the giggle test.

Though upon reading it, I am struck by two core points:

One is that big companies will be pressured by governments.
Ironically, Akamai isn't one of those as they're willingly in bed with
governments around the world. But I guess as the slides say, the
author isn't speaking on behalf of Akamai. That said - good, I want
governments to have to go to a company rather than to the user - the
company may have a legal team, the user may have hidden or otherwise
protected themselves. Hopefully the company is in a position to do
nothing or will take action to protect the user's basic liberties.

The second is a constant security nihilism. Yeah, a lot of stuff is
broken - so lets acknowledge it bit by bit and then fix it all.

I would encourage everyone to read the slides as the conclusion in the
presentation simply do not follow. If I had been in the audience when
they were presented, I would have been at the microphone objecting.
The idea that this convinced anyone is baffling.

It is clear that privacy concerns exist in many many different
protocols and that many protocols need to be fixed. Many people point
at other protocols as a way to punt on the issue for their own
protocol. The cycle continues and the privacy violations continue
without end.

> Please don't brush this argument off in favor of the "obvious" answer that
> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a
> lot of risk for virtually no gain. I was quite in favor of encrypted SNI
> before reading it, and I had to concede the point after. If we can come up
> with a way to do it easily, ok, but it's not an avenue worth spending too
> much time on.
>

The idea of splitting the world, as the slides do, into three basic
camps (liberal democracy with good traffic analysis, liberal democracy
with bad traffic analysis and horrible dangerous places) is simply not
serious. The idea that our liberal democracies do perfect traffic
analysis and so we should ensure *everyone* including *non-NSA*
attackers can do it for *free* is just bizarre to me. It is incorrect
as a conclusion to do nothing because some people somewhere *may* be
good at traffic analysis. The logic of the slides suggest that raising
the cost from a kid-in-a-cafe to NSA is proof that we shouldn't
bother. Again, the security nihilism monster appears. We should reject
this nihilism and fix the problem.

Encrypted SNI makes sense as it makes traffic analysis harder.
Encrypting DNS queries makes sense too. Composing it with other
systems may or may not make sense. Even when TLS is composed with a
tool to do traffic analysis resistance, the exit node of the
TA-resistance network can still do selective attacks based on SNI. In
that case the DNS is likely to be resolved at a different exit point.
Thus if we want to punt again and say, hey, traffic analysis
resistance is better left to Tor or something else, please consider
that plaintext selectors make Tor's job harder.

These changes make it more expensive and in some cases, it will stop
attackers who would otherwise be able to make an attack happen
undetected. It requires an attacker to spend more money on CPU, memory
and on other resources to do correlation across multiple collection
points.

Kicking the can down the road doesn't even begin to summarize why
leaving SNI unencrypted is incorrect. Metadata is a serious problem
and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF
TLS list), even in liberal democracies, helps to solve the problems we
face from mass surveillance.

All the best,
Jacob