Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3691130FF4 for ; Fri, 6 Jul 2018 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.092 X-Spam-Level: *** X-Spam-Status: No, score=3.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ROLEX=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 8_OP4smHfLXD for ; Fri, 6 Jul 2018 14:52:28 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 D761C131017 for ; Fri, 6 Jul 2018 14:52:27 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id y203-v6so4678626ywd.9 for ; Fri, 06 Jul 2018 14:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VpguPu6qFZX7Op0mTSpnoaEzfzipwV+nqgyEil+hcrk=; b=xBPmn46Wui/3Uau6lIDwo7IY1VTcTOKXEtULXj1DeLpCjyZA0FyuHcecSQunnF9mMX gAbrCWS8q+dwLqbABB584OFuo8jtroW8h2nya4Bt1JrPs4Qy8QYqx3DUq622P/SidcXT yL87RDmZSEGyrlpE+o77cxhwexA1gcyuTtmDtLsVRYCX5siTPJlCmZwlneyn87Qbyl1m F95TpVD5fD7V6FaVKPgv5z9WKVFCpi17mEjclYRoqFZC3uu7tuV5emrAqMeHDtANmo/+ z61Eh1jlp9h2vrCDUkC4DxVQz09FSSqZF3WX1AQ4/74ighT/r3yxL9h4PHzbK9hFkuEz 386w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VpguPu6qFZX7Op0mTSpnoaEzfzipwV+nqgyEil+hcrk=; b=IbDVe6w+LqBL7kKBmZc8uOV/uOcF7kyXRC0v/D3JBhjzNKOzpw3QHg5bb0eBqr5ilk OZHwdZ5UMm9N46WTMps2Bi+vy/UI2t1XxeEICS3LmVyu0mopMB8bIhx9qoX6Y5DFVEOY +tyH8Pt8JjJfva0xpJ/QHvsafiA8CmLiwyFz0yFvdynbuS4VWP2EwZYhIFiM9zk/u6En 48y3oAI8nKx0f5sQj/CDvnUbjPw0PbwAgSvvTyP7AzfoKTkE9x0F+8MeVu207NswrSPO syxYkJ9V9BZgZAlXBwVSdUGTmA8HLkNXrqfUPdf6fZGB6VMNCSMKov55OGs0Bav4ROIY mxoQ== X-Gm-Message-State: APt69E1HG9uP+aP5b37aZP/DfM6r30pMlYaHRo5Wst5V2qNl49R2cLm8 OJ/RjofmFqwc6QVoEL9PpVkphnc5XDtwc3dgnUGwqg== X-Google-Smtp-Source: AAOMgpdoYiH6cunWkZ1FjBVqImjVBfRcKOXFtqz+dEDSNEzqtZakh74aYKCJ/c+wzTZw21j+jGfD2lsZg2LDp9pllZQ= X-Received: by 2002:a81:918b:: with SMTP id i133-v6mr5931515ywg.175.1530913946994; Fri, 06 Jul 2018 14:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 14:51:46 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 14:51:46 -0700 Message-ID: To: Brian Sniffen Cc: "" Content-Type: multipart/alternative; boundary="000000000000fe27a705705bada4" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 21:52:30 -0000 --000000000000fe27a705705bada4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen wrote: > Eric Rescorla writes: > > > On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian > wrote: > > > >> Looks neat. > >> > >> 1) TFO DOS vector: is the idea servers will disable TFO under strain b= ut > >> not be able to disable ESNI? > >> > > > > I hadn't thought about it, but that seems right. I'm not really seeing > why > > this is a DOS vector? At present, if you're able to pass a routability > > test, you can force a server to do a DH exchange and a signature, so > > forcing them to do ESNI decryption doesn't seem like it's that much of = an > > amplification. > > This is the same worry I had talking about ESNI the first time: if > experiencing a lot of load, a server operator might like to route the > load-generating customers / apps / users to a different set of servers. > To do that, he needs to know which customers / apps / users are inviting > the load. Is this a flash crowd to exampleA.com or exampleB.com? > Having to do crypto to determine that makes it *much* more expensive. > It rules out a bunch of ways of doing it on a separate device that > doesn't have the decryption key. > Well, the glib answer is "nobody is making you do ESNI". More concretely, there are plenty of people who have to deal with DoS who don't have the luxury of segmenting traffic by SNI (e.g., Google), so I'm unpersuaded that this is a necessary part of DoS defense. > I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor, > Prolexic) and not give them the real TLS keys? Yes, the system is specifically designed to allow this. >> 2) =E2=80=9Cclients might opt to attempt captive portal detection to see= if they > >> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D > >> > >> If I=E2=80=99m operating a great firewall, I can use this to discover > dissidents, > >> right? Either they send me dangerous SNI values or they are configure= d > to > >> not disable ESNI, and taking the fifth is fatal. To protect them, I > think > >> nobody can have this mode. > >> > > > > This doesn't sound right to me. The idea here is that you only disable > ESNI > > if the attacker is able to generate a valid TLS connection to a > > *non-default* root, which means that they are MITM-capable, which natio= n > > state firewall operators typically are not. And of course if they are, > then > > you have real problems. Can you walk me through the flow you have in > mind. > > My nation-state operator adversaries typically are MITM-capable. Hunh. > And yes, I have real problems! Lucky me. > I don't think anything can protect you from attackers who have a trust anchor on your machine. That's contrary to the whole TLS threat model. > But to generalize: even if it can't be done at the GFWoC, it's still > dangerous if done a cafe at a time. > Cafes do not generally have trust anchors on your machine. > >> 3) How many bits does this offer? Hiding in a set of a million uniform > >> hosts is 20 bits, > > > > > > Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits > > strong in the sense that the attacker can do a computation of cost > 2^{20}.n > > > > > > and the nonuniformity will accrue to the adversary=E2=80=99s benefit. A= ctive > >> probing will unmask visitors to dissident sites. > >> > > > > I don't really follow this. Can you explain? > > I think it's at most 20 bits strong: the attacker can do a computation > of cost 2^{20}, and crack the anonymity. It involves 2^{20} > cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses. > I'm sorry, I'm not following you. Can you please describe the precise form of attack you have in mind. > But I think it's a *lot* weaker than 2^{20}: the needles of the > adversary's search are not uniformly distributed. So he can block the > most popular site for a day. That doesn't take off 1 bit; that takes > off the vast majority of the clients. If sites are on a power-law > distribution, it gets down to where the remaining 2^5 are rubber-hosable > in just a few experiments > I don't follow this either. At this point it would perhaps be helpful if yo= u drew a diagram or described the attack in a lot more detail. -Ekr > -Brian > > > -Ekr > > > > > > > > I worry that this tool is so weak against a GFW-style adversary for the > >> purpose of allowing dissident access to restricted web sites that it > will > >> be dangerous if released. But maybe I misunderstand the purpose. If > this is > >> just to keep Western ISPs from monkeying with traffic, sure, ship it. > >> Labelling the encryption with its strength as applied, or showing CDNs > and > >> ISPs how to work out some bounds, seems one way to help users understa= nd > >> whether this can help them or put them more at risk. > >> > >> -- > >> Brian Sniffen > >> > >> > > -- > Brian Sniffen > Akamai Technologies > --000000000000fe27a705705bada4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen <bsniffen@akamai.com> wrote:
Eric Rescorla = <ekr@rtfm.com> = writes:

> On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <bsniffen@akamai.com> wrote: >
>> Looks neat.
>>
>> 1) TFO DOS vector: is the idea servers will disable TFO under stra= in but
>> not be able to disable ESNI?
>>
>
> I hadn't thought about it, but that seems right. I'm not reall= y seeing why
> this is a DOS vector? At present, if you're able to pass a routabi= lity
> test, you can force a server to do a DH exchange and a signature, so > forcing them to do ESNI decryption doesn't seem like it's that= much of an
> amplification.

This is the same worry I had talking about ESNI the first time: if experiencing a lot of load, a server operator might like to route the
load-generating customers / apps / users to a different set of servers.
To do that, he needs to know which customers / apps / users are inviting the load.=C2=A0 Is this a flash crowd to exampleA.com or exampleB.com?
Having to do crypto to determine that makes it *much* more expensive.
It rules out a bunch of ways of doing it on a separate device that
doesn't have the decryption key.

We= ll, the glib answer is "nobody is making you do ESNI". More concr= etely,
there are plenty of people who have to deal with DoS who d= on't have
the luxury of segmenting traffic by SNI (e.g., Goog= le), so I'm unpersuaded
that this is a necessary part of DoS = defense.

=C2=A0
I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?=C2=A0

<= /div>
Yes, the system is specifically designed to allow this.




>> 2) =E2=80=9Cclients might opt to attempt captive portal detection = to see if they
>> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80= =9D
>>
>> If I=E2=80=99m operating a great firewall, I can use this to disco= ver dissidents,
>> right?=C2=A0 Either they send me dangerous SNI values or they are = configured to
>> not disable ESNI, and taking the fifth is fatal. To protect them, = I think
>> nobody can have this mode.
>>
>
> This doesn't sound right to me. The idea here is that you only dis= able ESNI
> if the attacker is able to generate a valid TLS connection to a
> *non-default* root, which means that they are MITM-capable, which nati= on
> state firewall operators typically are not. And of course if they are,= then
> you have real problems. Can you walk me through the flow you have in m= ind.

My nation-state operator adversaries typically are MITM-capable.=C2= =A0 Hunh.
And yes, I have real problems!=C2=A0 Lucky me.

I don't think anything can protect you from attackers who have = a trust anchor
on your machine. That's contrary to the whole = TLS threat model.

=C2=A0
But to generalize: even if it can't be done at the GFWoC, it's stil= l
dangerous if done a cafe at a time.

Caf= es do not generally have trust anchors on your machine.


>> 3) How many bits does this offer? Hiding in a set of a million uni= form
>> hosts is 20 bits,
>
>
> Well, I would say it's got an anonymity set of 2^{20}. It's no= t 20 bits
> strong in the sense that the attacker can do a computation of cost 2^{= 20}.n
>
>
> and the nonuniformity will accrue to the adversary=E2=80=99s benefit. = Active
>> probing will unmask visitors to dissident sites.
>>
>
> I don't really follow this. Can you explain?

I think it's at most 20 bits strong: the attacker can do a compu= tation
of cost 2^{20}, and crack the anonymity. It involves 2^{20}
cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

I'm sorry, I'm not following you.= Can you please describe the precise
form of attack you have in m= ind.

=C2=A0
But I think it's a *lot* weaker than 2^{20}: the needles of the
adversary's search are not uniformly distributed.=C2=A0 So he can block= the
most popular site for a day.=C2=A0 That doesn't take off 1 bit; that ta= kes
off the vast majority of the clients.=C2=A0 If sites are on a power-law
distribution, it gets down to where the remaining 2^5 are rubber-hosable in just a few experiments

I don't f= ollow this either. At this point it would perhaps be helpful if you
drew a diagram or described the attack in a lot more detail.

-Ekr


-Brian

> -Ekr
>
>
>
> I worry that this tool is so weak against a GFW-style adversary for th= e
>> purpose of allowing dissident access to restricted web sites that = it will
>> be dangerous if released. But maybe I misunderstand the purpose. I= f this is
>> just to keep Western ISPs from monkeying with traffic, sure, ship = it.
>> Labelling the encryption with its strength as applied, or showing = CDNs and
>> ISPs how to work out some bounds, seems one way to help users unde= rstand
>> whether this can help them or put them more at risk.
>>
>> --
>> Brian Sniffen
>>
>>

--
Brian Sniffen
Akamai Technologies

--000000000000fe27a705705bada4--