Re: [TLS] DNS-based Encrypted SNI

Eric Rescorla <ekr@rtfm.com> Fri, 06 July 2018 21:52 UTC

Return-Path: <ekr@rtfm.com>
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Fri, 6 Jul 2018 14:52:27 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id y203-v6so4678626ywd.9 for <tls@ietf.org>; 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: <m2va9skpo1.fsf@bos-mpeve.kendall.corp.akamai.com>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> <CABcZeBOZRQSo9J904yqucK_b8iGRb=EyL52rKkmrBqO1v=cBhA@mail.gmail.com> <m2va9skpo1.fsf@bos-mpeve.kendall.corp.akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 6 Jul 2018 14:51:46 -0700
Message-ID: <CABcZeBMC0L=W5XMdUrDFjqqX5ZKTaoUE3hGO13kOxX-iWA=wXg@mail.gmail.com>
To: Brian Sniffen <bsniffen@akamai.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fe27a705705bada4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5ufAhI0u7Uf_Xeg4iZTzmEShNvQ>
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." <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, 06 Jul 2018 21:52:30 -0000

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 strain but
> >> 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) “clients might opt to attempt captive portal detection to see if they
> >> are in the presence of a MITM proxy, and if so disable ESNI.”
> >>
> >> If I’m operating a great firewall, I can use this to discover
> dissidents,
> >> right?  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 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 nation
> > 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’s 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 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 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 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 understand
> >> whether this can help them or put them more at risk.
> >>
> >> --
> >> Brian Sniffen
> >>
> >>
>
> --
> Brian Sniffen
> Akamai Technologies
>