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

Nick Mathewson <nickm@torproject.org> Fri, 25 September 2015 13:49 UTC

Return-Path: <nick.a.mathewson@gmail.com>
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 176A71A19F8 for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 06:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Level:
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 PMe8D0Km2III for <tls@ietfa.amsl.com>; Fri, 25 Sep 2015 06:49:50 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 F01AE1A19EC for <tls@ietf.org>; Fri, 25 Sep 2015 06:49:49 -0700 (PDT)
Received: by lacdq2 with SMTP id dq2so43704294lac.1 for <tls@ietf.org>; Fri, 25 Sep 2015 06:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=H1ohVYkPEJDbsbYn5yiY6m6diqI32tSGGO/wKZliF5E=; b=aFRv3qiPJe6sR4yiECIfyV1ZxhjEFrz1aczB1lhPr5OX5xMniMUsYvEkObYeSPEK55 QuMUbJXOG2EZsfCz6ziyH6lkZSEMXZQ6DmVReQfwnH5Kb4pGF2oZrMWHOR3lWvbZUrpY m7wBFGKLW+Aoy4nxIff55ygl2OlLyWSBy7u+rb11tWy95H9e4F0KQo7c5myaEJCn2Xzd WIR0PcnW/V3dzLJjf/vBM72/7/s0oREVXhzn3Vp54/Y59Vd88z7KynEDTWn8IWzcqbLQ 6Zhyc0Evaq5JM9i1WhxBHuuq1jKn97ioYlNFGtjE95aS+7VfmSGRuW6w8S0xJw90ugr8 jthQ==
MIME-Version: 1.0
X-Received: by 10.152.6.34 with SMTP id x2mr1412079lax.120.1443188988061; Fri, 25 Sep 2015 06:49:48 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.112.201.74 with HTTP; Fri, 25 Sep 2015 06:49:47 -0700 (PDT)
In-Reply-To: <e6259a91ef61490696d39c4e7515c470@ustx2ex-dag1mb1.msg.corp.akamai.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> <CABtrr-Vi5CqiU9Wvs3vkr_beP4gGX9sSczAy2FOUFags4dsK8w@mail.gmail.com> <e6259a91ef61490696d39c4e7515c470@ustx2ex-dag1mb1.msg.corp.akamai.com>
Date: Fri, 25 Sep 2015 09:49:47 -0400
X-Google-Sender-Auth: lin2wl001FQyA6KZe6N3DKCVG6Q
Message-ID: <CAKDKvuxXOYBTD9N9kAxh7kxWP74zzcQBcnnNTA3qFEbs5eKL8Q@mail.gmail.com>
From: Nick Mathewson <nickm@torproject.org>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NMVBIRifOMwB3BpKwXIACTKA-Jo>
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: Fri, 25 Sep 2015 13:49:52 -0000

On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich <rsalz@akamai.com>; wrote:
> We discussed this before.  Not that we can't discuss it again.  Here's a link to slides I presented at the Toronto Interim in July 2015.
>
>         https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing
>


Thanks for that link, Rich!

Please forgive me if my analysis has already been gone over, but I
believe that there are at least three problematic aspects in the
argument as presented in your slides.

1) Entrenchment of codependent vulnerabilities

This is a strong antipattern in security design, and it's been
practiced by some of the great minds of the field, but I think it's
fundamentally mistaken. Here's how it works:

There are two systems, A and B.  Each has a problem that enables some
kind of attack. The people who maintain system A say: "There is no
point in fixing A, because any attacker who breaks A could achieve the
same results via B."  But the people who maintain system B say: "There
is no point fixing B because any attacker who breaks B can achieve the
same results via A."

Both groups are using solid logic: neither one of them would
materially improve user security by fixing the vulnerability in their
system.  The Codependent Vulnerability antipattern arises when no
progress is ever made, because each group decides that the problems
outside its control will probably never be fixed.

In your slides, I see several instances of codependent vulnerabilities:

a) Improved DNS security vs Encrypted SNI

The lack of security in current DNS usage is taken to justify not
improving SNI privacy. But in discussions about DNS privacy,
vulnerabilities in other protocols are frequently taken as
justification for not improving DNS privacy.

b) Traffic analysis vs encryption

Traffic analysis is indeed strong today, but it's not omnipotent, and
good research on resisting it is happening all the time.  But if we
take the weaknesses of TLS against traffic analysis a a permanent
feature of the world, then such research will have less opportunity to
bear fruit, since TLS will entrench the problems that
anti-traffic-analysis research cannot yet solve.

c) Technical attacks vs rubber-hose attacks

See point 2 below.


2) Attacks are not equally costly and do not scale equally well.

It's not sufficient to say "This defense will not render the attack
impossible; therefore it is useless"; we also need to consider whether
the defense will render the attack _more expensive_.

Even for regimes unconcerned with fair play and regimes with
significantly intrusive attitudes to civil liberties... intimidating
citizens, applying political pressues, and backdooring infrastructure
are not zero-cost operations.  In nearly all cases, ithese attacks are
more difficult and costly than simply reading bytes off the wire.


3) Censorship vs surveillance.

The analysis in the slides is concerned with attackers against privacy
rather than attackers against availability.  But IMNSHO, both kinds of
attacker are a significant threat to human rights.

Unencrypted SNI makes a censor's job extremely easy.  In today's TLS,
it's trivial to block targeted domains hosted at a provider without
blocking ones where the censors consider access desirable.  Encrypting
SNI would make this kind of blocking more difficult and technically
expensive.


To be fair, encrypted SNI would probably make trouble for providers
who host some censored and some uncensored services.  Plaintext SNI
does make it easier for censors to be selective, and thereby makes it
easier for hosting providers to avoid conflicts and drama.


best wishes,
-- 
Nick Mathewson
<nickm@torproject.org>;