Re: [TLS] DNS-based Encrypted SNI

[Brian Sniffen <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

> On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <[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?
>>
>
> 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