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
- [TLS] Encrypting record headers: practical for TL… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Tony Arcieri
- Re: [TLS] Encrypting record headers: practical fo… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bill Cox
- Re: [TLS] Encrypting record headers: practical fo… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Short, Todd
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Jim Schaad
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… John Mattsson
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- [TLS] Fully encrypted and authenticated headers (… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Fully encrypted and authenticated heade… Martin Thomson
- Re: [TLS] Fully encrypted and authenticated heade… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Mike Copley
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Stephen Farrell
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Ilari Liusvaara
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Mill
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Martin Thomson
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jeff Burdges
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum