Re: [TLS] DNS-based Encrypted SNI

Brian Sniffen <bsniffen@akamai.com> Fri, 06 July 2018 21:41 UTC

Return-Path: <bsniffen@akamai.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 E3CC713107B for <tls@ietfa.amsl.com>; Fri, 6 Jul 2018 14:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.29
X-Spam-Level: **
X-Spam-Status: No, score=2.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ROLEX=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=akamai.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 bOU2YnBV7hVT for <tls@ietfa.amsl.com>; Fri, 6 Jul 2018 14:41:37 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A051310AF for <tls@ietf.org>; Fri, 6 Jul 2018 14:41:36 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w66Lfaer006489; Fri, 6 Jul 2018 22:41:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=29o8M5M9Ef4NhJx1I9+ck/XwuCDOcjrV6dbaNMRohBY=; b=bl7kyQSG0EunVmcg9H6074LeiAn0MAwNbwoH5AIPj1geOxV0pazQCO/G76R6XWERY965 bqzsOzdUnHubC/FbcfI8JLHzgq6oaQMt3VPr5Ym1cmEOSz8Nq74/mAj2WCR/opUy49ui kU7D9yD66+ytq5cuPmeL5IhHgeeXVypzOkL7KQcAitjL/1bNrawgFKM4rZ0j2PhVU/w9 687LwPBTuw3DV285wo8+707XtpJcYR5E3dVEIs4WBYh1rwM7gnlO0KlQk+Eqd0P1s59o mNaM3iKza4LwJLC0vE0JyIzo+6eDybvzVonStR4brcOAZA8cAeQs3m23/Ljfd7JRx11E Pw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2k269j9ekf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 22:41:36 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w66LYqgS006220; Fri, 6 Jul 2018 17:41:34 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jx56vhwkt-1; Fri, 06 Jul 2018 17:41:34 -0400
Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.19.33.76]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A8D231FC0E; Fri, 6 Jul 2018 21:41:34 +0000 (GMT)
From: Brian Sniffen <bsniffen@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "\<tls\@ietf.org\>" <tls@ietf.org>
In-Reply-To: <CABcZeBOZRQSo9J904yqucK_b8iGRb=EyL52rKkmrBqO1v=cBhA@mail.gmail.com>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> <CABcZeBOZRQSo9J904yqucK_b8iGRb=EyL52rKkmrBqO1v=cBhA@mail.gmail.com>
Date: Fri, 06 Jul 2018 17:41:34 -0400
Message-ID: <m2va9skpo1.fsf@bos-mpeve.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060241
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060242
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/R0UHJjCI-tKSeMfFl7RMmA5QC8Y>
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:41:47 -0000

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.

I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?  That takes away the
routability test---they just test a sample of what's on the wire, but
that's probably okay.

>> 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.

But to generalize: even if it can't be done at the GFWoC, it's still
dangerous if done a cafe at a time.

>> 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.

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.

-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