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 E5C85130E10 for ; Fri, 6 Jul 2018 19:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 4H9BFbAw4V61 for ; Fri, 6 Jul 2018 19:43:54 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 DACC31277C8 for ; Fri, 6 Jul 2018 19:43:53 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id e23-v6so4339082ywe.13 for ; Fri, 06 Jul 2018 19:43:53 -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=K11leoC/6ObnbII22/nUsrgu5AdYs41LgXin2pKeCME=; b=aybuxWWW7aOR6X307dsn2M65UpwBPYFTO3pNiFW+pocOZh0f/ZxggXjDg6Rhp9v0eF 0geLGw6G42HysuGnC/+3WM5njzqfPaJUJSjc2M37L4ehDhMA2kHuwXqJ5/W+Szei+HZH m0kyFdraqRy8L8NfO8Vho6oxMmjJ1nhDEBrJL6xaTD7xxnx8/WoFz+j8ywiAL8Th3MGS yLAJ7PlmKAotgRDYL5hW9cc6qJWJNQgaxsVnpH8R/8mFGo0ESPln8Hx7AZmIz9b4mTvx XbfvxM/VbwbAbbudAKtWK/XFNDJrsEq+slgmm4agP2K0KsN9Kv8ZhIAv88JICgaLLCtX sEUg== 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=K11leoC/6ObnbII22/nUsrgu5AdYs41LgXin2pKeCME=; b=PTTOXOWonjvymqzScRWh6p+ZuCqbGlyfiY0zxz7aySmEC+Wi5z/vnwvOsPACaGO7tc FJ/E3OlDaQ29ovvmSFUILGvjm6MGsX2cRRiIyVxyeJP+uUOKILTn66bpf+tK3dNI54PJ ksqqGGH615HrBD98hxssyAiZzMJrldzFOEtpACdIKRUmxCa5vNYqmasB3MmI1J7n4F8P lzsoGKOAyivReuSdMnWxGD7UBXKkOtSw7QxYIQ/A6xxxaaFfqo8GT6nnuk73/JT0SyTN dNxhavfdNWzF/9K04S+JFP/2FTKakuQPDue0HtGeBGxYRk4yKKvXVgwwi98Tp1PXrHdt asTw== X-Gm-Message-State: APt69E2LMT+23p/vYXDv/dmnLaoQZrBeK/ymdg8kylQuS+glsM9Qbx6N zyMUhvpyzsEdETX9057gZexujK/drFbCQfH5zNiggwp4 X-Google-Smtp-Source: AAOMgpcZ563pC6I3iemB1baawEjlawbWYbmXyTsf+3B2kfIQ5X2MH7S54oomSzpQ6xKXRXwiZ3l60ZefkIYwD0y0eZQ= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr5923575ywf.167.1530931433014; Fri, 06 Jul 2018 19:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 19:43:12 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 19:43:12 -0700 Message-ID: To: "Short, Todd" Cc: "" , "Sniffen, Brian" Content-Type: multipart/alternative; boundary="0000000000003da30f05705fc020" 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: Sat, 07 Jul 2018 02:43:57 -0000 --0000000000003da30f05705fc020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd wrote: > > (Pardon phone typos below.) > -- > -Todd Short > // Sent from my iPhone > // "One if by land, two if by sea, three if by the Internet." > > > On Jul 6, 2018, at 4:43 PM, Eric Rescorla wrote: > > > > 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 pa= th >> can prevent the use of optional security features. >> >> Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESNI = DNS >> 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 t= o > 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 > > > Which makes this mechanism potentially useless. If it was mandatory in > TLSv1.3, then trying to block encrypted SNI would be break a lot more > sites, and might have to be allowed. > I'm not sure I agree with this, but I also don't see a lot of point in debating it. > 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. Th= is >> 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 whe= re >> 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 no= t) > use the same keys, and hence have the same record_digest. Thus, > record_digest is just an alias for anonymity set. The client-facing serve= r > 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 ti= me. > > > It's implied that record_digest is/can be used to select the "origin > server". If not, then the wording should be clarified. > I'm not sure where you're getting this from. Here's the text in question: " o If the EncryptedSNI.record_digest value does not match the cryptographic hash of any known ENSIKeys structure, it MUST abort the connection with an "illegal_parameter" alert. This is " Anyway, if you think this should be clarified, please feel free to submit a PR. > Again, because this is optional, the (initial) set of servers that use > ESNI will be small, and can be reasonably determined.The anonymity set, a= t > the least, can be reduced by destination address via reverse-DNS. CDNs wi= ll > resolve domains to different IPs (on various metrics) which could leak > information to help narrow down the actual domain. So, it still can expos= e > a set of possible destination domains that the user is attempting to reac= h. > Yes, it's true that the client-facing servers need to take steps to put people in the same anonymity set on the same IP. In general, we have a pile of sources of privacy leakage (cert in the TLS handshake, DNS, SNI, IP addr, traffic analysis, etc.). In order to make any progress, we're going to need to tackle them one at a time. My fear is that there's enough potential leakage that something should be > mentioned in security considerations. > Again, PR welcome. -Ekr > > > 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 < >> bsniffen=3D40akamai.com@dmarc.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 di= ssidents, >> 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 thin= k >> 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 wil= l >> 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 a= nd >> 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 >> >> >> >> > --0000000000003da30f05705fc020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd <tshort@akamai.com>= wrote:

(Pardon phone typos below.)
--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."= ;


On Jul 6, 2018, at 4:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <tshort@akamai.co= m> wrote:
Fundamentally, unless this type of protection is baked into the protoc= ol from the beginning, and is not an add-on option, any one/thing in the pa= th can 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 that if you control = DNS, it's basically game over, which is why this is most attractive wit= h DOH to some location not controlled by the censor. However, if you *do* h= ave DOH, then the client shouldn't fall back, with the result that blocking ESNI blocks all ESNI-enabled sites, no= t just those which are sensitive

Which makes this mechanism potentially useless. If it was manda= tory in TLSv1.3, then trying to block encrypted SNI would be break a lot mo= re sites, and might have to be allowed.=C2=A0
=
I'm not sure I agree with this, but I also don't see= a lot of point in debating it.

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

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 misunderstanding the design here. All of the ESNI-e= nabled sites behind the same client-facing server (split mode or not) use t= he 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 back= end server. It uses the record_digest to find which of the keys it has offe= red 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.

It's implied that record_digest is/can be used to select th= e "origin server". If not, then the wording should be clarified.= =C2=A0

I'm not sure where y= ou're getting this from. Here's the text in question:
"=C2=A0=C2=A0 o=C2=A0 If the EncryptedSNI.record_digest va= lue does not match the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic hash= of any known ENSIKeys structure, it MUST abort
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 the connection with an "illegal_parameter" alert.=C2=A0 Th= is is
"

Anyway, if you think this should b= e clarified, please feel free to submit a PR.

=C2= =A0
Again, because this is optional, the (initial) set of servers that use= ESNI will be small, and can be reasonably determined.The anonymity set, at= the least, can be reduced by destination address via reverse-DNS. CDNs wil= l resolve domains to different IPs (on various metrics) which could leak information to help narrow down = the actual domain. So, it still can expose a set of possible destination do= mains that the user is attempting to reach.
= =C2=A0
Yes, it's true that the client-facing servers need to = take steps to put people in the same anonymity set on the same IP. In gener= al, we have a pile of sources of privacy leakage (cert in the TLS handshake= , DNS, SNI, IP addr, traffic analysis, etc.). In order to make any progress= , we're going to need to tackle them one at a time.


My fear is that there's enough potential leakage that something sh= ould be mentioned in security considerations.=C2=A0

Again, PR welcome.

-Ekr




Ah, but if the CDN maps the shared-ESNIKeys domains to be different IP= s, 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.= =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 ne= at.

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
https://www.ietf.org/mailman/listinfo/tl= s



--0000000000003da30f05705fc020--