Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla <[e-mail]>]

On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd <[e-mail]> 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 <[e-mail]> wrote:
>
>
>
> On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <[e-mail]> 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 path
>> can prevent the use of optional security features.
>>
>> Don’t 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 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
>
>
> 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. This
>> 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 where
>> 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.
>
>
> 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, at
> the least, can be reduced by destination address via reverse-DNS. CDNs will
> 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 domains that the user is attempting to reach.
>

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’t 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
>> // [e-mail]
>> // "One if by land, two if by sea, three if by the Internet."
>>
>> On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <
>> bsniffen=[e-mail]> wrote:
>>
>> Looks neat.
>>
>> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
>> not be able to disable ESNI?
>>
>> 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.
>>
>> 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’s
>> 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 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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=jO6FtGxHwI8V5rcKNJJ3nyWt30nuYRxDsMw4SrDjQv8&s=ugN6SXThjZ5obqv2V3Ved7ilhh8n8gXdFsOVajJ9zR0&e=>
>>
>>
>>
>