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 76893130DE3 for ; Fri, 6 Jul 2018 13:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 8XQaX4Xj3Zaq for ; Fri, 6 Jul 2018 13:43:13 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 722F9130DDC for ; Fri, 6 Jul 2018 13:43:13 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id k18-v6so4621770ywm.11 for ; Fri, 06 Jul 2018 13:43:13 -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=kPC6yI6AQpt/m8NeAi4wleex9+g0fHENsrdeum4Xttg=; b=VgQHYvqUaQ5MJ6XMCVeoK3WrsMUI+X1lhg7y0Btdll/VjRvnjLAI+VhM44l4X5S7Ll xBE/yn6JhY8NLCGJXdcSvySFLljQwdAz2Yj0WHYhgoFciTO3UYrfqxcOVBmhIxvamVyh 0AYfEjRtVEhYPw5uBrAlaHsz9n0rrC/kKDFI9pLiS9JUtGbMysy4Pl1BFARMf81aYcbf N5x4/sqLPJzq4GBaIHs6CYr6WIjnrJHr9rCzkeqIEP5zSeVWuIPBUKf2W8Pyzz8iUg2A +zaIe0aM6CWWlzmlZu1LWVVKog8MLa6bv4u0B/3+lyaB476OqLaas0aiSxqH0FEcaL/V DdDw== 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=kPC6yI6AQpt/m8NeAi4wleex9+g0fHENsrdeum4Xttg=; b=sGATQTjDbhTFS9Mh7ZEvCcket5qNlnqJFzQJ+vWwwsuzxs+z0l9v2Z2OKIof8jV/wp 8D1Ry2hVtvp/urOoSLnYJazLlN4fh/5LX1TLEL9ZFqzX3wts1pG2eZk7tMSu8Z3VTDD1 i4xekLX4nsETB4UdXSSBT7V/FgOU/EHdpXCXgu5bLOI2KcfWe4TGHXrpux0mihdjtyeC uMWHnA1TD+CqI/xHtRN+52l4Hxg4Vm7WuKi4zX7GTUqa49eGy76WL5uYYOcY6TFIz6bp 8IhdETAFCvGo/rdv9bjUSZV8NwPZX0xOmBwSRg20zAp/HkXXuRP/Yw79qXFKJNFdlvjT NqMg== X-Gm-Message-State: APt69E2+BWNv7kps3aRbiH3j2bPR/up+pV3vbDC0VKQoy0QLs6ZJkVCp iR6oul+jIX5ehapykjmUJIUGRE42cSdBB17B3polCw== X-Google-Smtp-Source: AAOMgpe7vQsw7rpxNAYmvHM2UDv4146zwgD6Kdac9/nLig3eGgXwA7QBzSmHxNggDBt0pai+8HefNHUdgIC5xpIcABM= X-Received: by 2002:a81:2ec8:: with SMTP id u191-v6mr5621847ywu.430.1530909792325; Fri, 06 Jul 2018 13:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 13:42:31 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 13:42:31 -0700 Message-ID: To: "Short, Todd" Cc: "" , "Sniffen, Brian" Content-Type: multipart/alternative; boundary="0000000000005ae93505705ab6d7" 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 20:43:17 -0000 --0000000000005ae93505705ab6d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd wrote: > Fundamentally, unless this type of protection is baked into the protocol > from the beginning, and is not an add-on option, any one/thing in the pat= h > can prevent the use of optional security features. > > Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESNI D= NS > requests/responses, block the use of ESNI, etc. > These are sort of different things. It's true that if you control DNS, it's basically game over, which is why this is most attractive with DOH to some location not controlled by the censor. However, if you *do* have DOH, then the client shouldn't fall back, with the result that blocking ESNI blocks all ESNI-enabled sites, not just those which are sensitive > A firewall can also use the record_digest to determine the destination, > without even decrypting the ESNI. It just calculates the possible > record_digests of the blocked sites; since the information is public. Thi= s > will make it appear that ESNI is supported (for legal sites), but still > block the use to illegal sites. > > Or even do a reverse-DNS lookup on the destination IP, discover all the > domains there, and then calculate the possible record_digests to see wher= e > the user is going. > > This could be mitigated by having the same ESNIKeys for different > websites, but that means the "Split Mode Topology" is broken as the > record_digest cannot be used by the Client-Facing Server to select a > Backend Server. > I think you may be misunderstanding the design here. All of the ESNI-enabled sites behind the same client-facing server (split mode or not) use the same keys, and hence have the same record_digest. Thus, record_digest is just an alias for anonymity set. The client-facing server does not use the record_digest to select the backend server. It uses the record_digest to find which of the keys it has offered and then uses that key to decrypt the true SNI. Note that in some naive sense you don't need a record_digest at all. It's just there to facilitate the client-facing server having multiple valid ESNI key sets (e.g., for rollover) at one time= . Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, > then doesn=E2=80=99t matter. This is not the case, as the IP address can = now be > used along with the ESNIKeys to know what the final destination is. > Yes, you need to use the same IPs. -Ekr > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Jul 3, 2018, at 10:26 AM, Sniffen, Brian ietf.org> wrote: > > Looks neat. > > 1) TFO DOS vector: is the idea servers will disable TFO under strain but > not be able to disable ESNI? > > 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 dis= sidents, > right? Either they send me dangerous SNI values or they are configured t= o > not disable ESNI, and taking the fifth is fatal. To protect them, I think > nobody can have this mode. > > 3) How many bits does this offer? Hiding in a set of a million uniform > hosts is 20 bits, and the nonuniformity will accrue to the adversary=E2= =80=99s > benefit. Active probing will unmask visitors to dissident sites. > > 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 an= d > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --0000000000005ae93505705ab6d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <tshort@akamai.com>= ; wrote:
Fundamentally, unless this type of protection is baked into the protocol fr= om the beginning, and is not an add-on option, any one/thing in the path ca= n prevent the use of optional security features.

Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESN= I DNS requests/responses, block the use of ESNI, etc.

These are sort of different things. It's true th= at if you control DNS, it's basically game over, which is why this is m= ost attractive with DOH to some location not controlled by the censor. Howe= ver, if you *do* have DOH, then the client shouldn't fall back, with th= e result that blocking ESNI blocks all ESNI-enabled sites, not just those w= hich are sensitive

=C2=A0
A firewall can also use the record_digest to determine the destination= , without even decrypting the ESNI. It just calculates the possible record_= digests of the blocked sites; since the information is public. This will ma= ke it appear that ESNI is supported (for legal sites), but still block the use to illegal sites.<= /div>

Or even do a reverse-DNS lookup on the destination IP, discover all th= e domains there, and then calculate the possible record_digests to see wher= e the user is going.

This could be mitigated by having the same ESNIKeys for different webs= ites, but that means the "Split Mode Topology" is broken as the r= ecord_digest cannot be used by the Client-Facing Server to select a Backend= Server.

I think you may be mis= understanding the design here. All of the ESNI-enabled sites behind the sam= e client-facing server (split mode or not) use the same keys, and hence hav= e the same record_digest. Thus, record_digest is just an alias for anonymit= y set. The client-facing server does not use the record_digest to select th= e backend server. It uses the record_digest to find which of the keys it ha= s offered and then uses that key to decrypt the true SNI. Note that in some= naive sense you don't need a record_digest at all. It's just there= to facilitate the client-facing server having multiple valid ESNI key sets= (e.g., for rollover) at one time.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, then doesn=E2=80=99t matt= er. This is not the case, as the IP address can now be used along with the = ESNIKeys to know what the final destination is.=C2=A0

Yes, you need to use the same IPs.

-Ekr


--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=3D40akamai.c= om@dmarc.ietf.org> wrote:

Looks neat.

1) TFO DOS vector: is the idea servers will disable TFO under strain but no= t be able to disable ESNI?

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 dissi= dents, right?=C2=A0 Either they send me dangerous SNI values or they are co= nfigured to not disable ESNI, and taking the fifth is fatal. To protect the= m, I think nobody can have this mode.

3) How many bits does this offer? Hiding in a set of a million uniform host= s is 20 bits, and the nonuniformity will accrue to the adversary=E2=80=99s = benefit. Active probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the pur= pose of allowing dissident access to restricted web sites that it will be d= angerous if released. But maybe I misunderstand the purpose. If this is jus= t to keep Western ISPs from monkeying with traffic, sure, ship it.=C2=A0 Labelling the encryption with its stren= gth 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 mo= re at risk.

--
Brian Sniffen

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--0000000000005ae93505705ab6d7--