On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen <bsnif...@akamai.com> wrote:
> Eric Rescorla <e...@rtfm.com> writes:
>
> > 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.
>
> 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.
>
Well, the glib answer is "nobody is making you do ESNI". More concretely,
there are plenty of people who have to deal with DoS who don't have
the luxury of segmenting traffic by SNI (e.g., Google), so I'm unpersuaded
that this is a necessary part of DoS defense.
> I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
> Prolexic) and not give them the real TLS keys?
Yes, the system is specifically designed to allow this.
>> 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.
>
I don't think anything can protect you from attackers who have a trust
anchor
on your machine. That's contrary to the whole TLS threat model.
> But to generalize: even if it can't be done at the GFWoC, it's still
> dangerous if done a cafe at a time.
>
Cafes do not generally have trust anchors on your machine.
> >> 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.
>
I'm sorry, I'm not following you. Can you please describe the precise
form of attack you have in mind.
> 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
>
I don't follow this either. At this point it would perhaps be helpful if you
drew a diagram or described the attack in a lot more detail.
-Ekr
> -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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
