Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Joseph Lorenzo Hall <joe@cdt.org> Tue, 22 September 2015 18:21 UTC

Return-Path: <jhall@cdt.org>
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 A5A4D1A9250 for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 11:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 guRH0Voo1m3H for <tls@ietfa.amsl.com>; Tue, 22 Sep 2015 11:21:02 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 F27D61A908A for <tls@ietf.org>; Tue, 22 Sep 2015 11:21:01 -0700 (PDT)
Received: by lagj9 with SMTP id j9so23448417lag.2 for <tls@ietf.org>; Tue, 22 Sep 2015 11:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VDRtgjFnxeAoZ2JiLLkd0F0Lbm7GVGqqw0DKxReBLEc=; b=oiriTE0fXFPdh+aG6wubbDe4ukqENRYhPyLqQRShMBTEVs+y1ay8F9oyWsnpvxQPlI 3KIhIu0NB9qoC/FhtRHpnnVEsT4OFYVPKgILO8cFePW0vywzzfqjnJHh+3mNec+hC/KE TxA1SCcYjQSQr8v7QaxetnmBV3apBTGASR4ys=
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:from:date :message-id:subject:to:cc:content-type; bh=VDRtgjFnxeAoZ2JiLLkd0F0Lbm7GVGqqw0DKxReBLEc=; b=h2ivFe9S4OHxJJhD9mA1qriSlo4kS0TtlnR+UatMtFtla3EmG50S9zBrfmQK0Gs2m+ +mNo7gYaw3KRdez7uqXsAauWx0c8aYDDbg42T9rIdci9I0ZMB6a9se0i3D+pur7MJ7Mb zW1bBa/QIhp89kIjmBxSlNoLXipIXW/ENGeU9CLrzzwcoS1bijI5yPisX8a7RwMV2kpM /jdpYEPxsB0XrbkzTpi6C6JT+jKjOK5b2Uu9mDINyfiVTD2NHrdonsqGptU9Tn1pzAI+ ic3ncxbPA6oiMY2Z8ZIAzm4pPtKEri/rFP0vrPHs3/NCLMHQHXYjwo9sYbZLgHm8Imk9 Q1LA==
X-Gm-Message-State: ALoCoQmwxZasmAH7NC3aA4Fd6wm0lqGRaEg0ZV4767SMTj2SKSKcbrhpmwYw55ENjrARnjiG3IaW
X-Received: by 10.112.156.167 with SMTP id wf7mr10240113lbb.88.1442946060093; Tue, 22 Sep 2015 11:21:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.199.138 with HTTP; Tue, 22 Sep 2015 11:20:40 -0700 (PDT)
In-Reply-To: <CAFggDF14LALxYZMVYzRepNU61tgPERTJyn+FgHWD13CpRcbLAQ@mail.gmail.com>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CAL6x8mfDjYAhOwvBY-tFO-407E9U+SaknJnuh_dCEEUbWJZZWw@mail.gmail.com> <20150828144932.GH9021@mournblade.imrryr.org> <201508281213.03823.davemgarrett@gmail.com> <20150828162251.GM9021@mournblade.imrryr.org> <871tdr23fh.fsf@alice.fifthhorseman.net> <CAFggDF14LALxYZMVYzRepNU61tgPERTJyn+FgHWD13CpRcbLAQ@mail.gmail.com>
From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Tue, 22 Sep 2015 14:20:40 -0400
Message-ID: <CABtrr-Vi5CqiU9Wvs3vkr_beP4gGX9sSczAy2FOUFags4dsK8w@mail.gmail.com>
To: Jacob Appelbaum <jacob@appelbaum.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/W4nGV7fznpEqky8HExrzbJBdcoA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
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: Tue, 22 Sep 2015 18:21:03 -0000

On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum <jacob@appelbaum.net>; wrote:
> On 9/21/15, Daniel Kahn Gillmor <dkg@fifthhorseman.net>; wrote:
>> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni <ietf-dane@dukhovni.org>;
>> wrote:
>>> So the client would now need to cache some session data by transport
>>> address, and other data by name and port.  That's rather complex.
>>
>> This is already done by HTTP/2 clients, since they can access multiple
>> servers at the same address:port combination.
>>
>>> And how often will the same client visit multiple servers at the
>>> same transport address?
>>
>> *.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.
>>
>>> I don't really see this as viable or worth the effort.
>>
>> I disagree -- the metadata leaked to a passive attacker by mandatory SNI
>> is a valuable signal.  It is worth trying to protect it.
>
> I agree - this metadata is usable as a selector for automated
> surveillance and for automated exploitation.

I agree with Jake and DKG wholeheartedly.

I'd add that in addition to surveillance and exploitation, cleartext
SNI will be useful for censors at various scales... the same property
that it's useful for (distinguishing which domain at an endpoint a TLS
conversation is for), can be used to impair or drop flows.

I realize there is a small minority of people that participate in TLS
WG that feel very strongly about designing a way to have encrypted
SNI, but I'd really hope that we can find a way to do it, and that
it's not considered too massive of an effort.

The uses in which we would want to harden TLS connections against
surveillance, exploitation, and censorship will seem to only grow, and
having it baked into the infrastructure (and done well) will mean we
will have much more deployed ability to resist these kinds of network
attacks.

>>
>>> I don't think SNI hiding is viable without encryption at the
>>> transport or network layers.
>>
>> any encrypted SNI is effectively acting as a shim for transport
>> encryption, yes.  Then again, TLS is itself "transport layer security",
>> so we should try to provide it at least as an option.
>
> In an ideal world: using ephemeral keys, we must be able to have usage
> of the protocol that is selector free.
>
>>
>>> And there's still a metadata leak via DNS which may prove difficult to
>>> address.
>>
>> The DNS community is working to address the DNS leak in DPRIVE.  The TLS
>> community should be working to fix its own part of the metadata leak.
>>
>
> Agreed, strongly.
>
> All the best,
> Jacob
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871