On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <bsnif...@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.
> 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.
> 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?
-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
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
