Re: [TLS] About encrypting SNI

On Mon, Apr 14, 2014 at 8:08 PM, Salz, Rich <rsalz@akamai.com> wrote:
>> I think Alyssa Rowan's concern elsewhere in this thread about the "circular argument of doom and defeat" applies here too.
>
> I think it's a little too simple a way to view things. Our goal isn't to make Eve's job as hard as possible, it's to make the best set of trade-offs we can, for the ovewrall Internet.  As myself and others have pointed out, encrypting the SNI has some real drawbacks and might not accomplish what is desired. If we decide to not support it, it can purely be an evaluation of the trade-offs.

It all depends on the mechanism that is proposed, and how that works.
The mechanism in the current TLS 1.3 doesn't actually work: a censor
can break a few connections to see what you are looking at, then take
a look himself to see if they want to censor it. Even if we did have a
magic mechanism that encrypted the handshake without knowing to whom
it was to be encrypted (I'm sure someone will dig up an IACR paper
that presents a wildly impractical solution using fully homeomorphic
encryption) a censor could probably take a good guess as to what
everyone was looking at, especially from interaction patterns.

Censors are generally insensitive to collateral damage. Turkey denied
access to all of Twitter, and Pakistan all of Youtube (for everyone
worldwide once) over a small amount of subversive content on each. Not
to put anyone on the spot, but if you think a major hosting provider
is going to bat for you while getting bomb threats and periodically
sitewide blocks, you're nuts. They aren't. It isn't their business,
and the ones who make it their business are usually collateral damage
for a censor as people who don't want to take the cost of getting
blocked.

Frequently changing IP address and using DNS to send people there
doesn't work: the censor knows how to find DNS entries also. I'm not
sure what the threat that encrypted SNI is supposed to protect against
is: a passive observer looking for connections to a website on shared
hosting, insensitive to collateral damage? A merely curious teenager
armed only with wireshark, and no idea of what the websites look like?
The Great Firewall of China?

Finally, a sufficiently motivated censor could cut off all TLS 1.3
entirely if they couldn't break it. Browsers would fallback to TLS
1.2. Some censors are that motivated: they threaten publishers with
death and dismemberment

Now, the best mechanism I can think off would be to use DNS to preload
a per-IP SNI encryption key, or have the handshake optionally involve
getting one. But I still can't figure out how to authenticate the
gotten key without a lot of complexity. The best solution is for the
client and server to do a DH, then pass the desired website (which
might get you investigated when the initial handshake is intercepted),
and have that cert sign the handled DH, then go back and do a TLS
connection. Ugh.

Make a clean, per-IP solution, and you solve the big problem. However,
I think censors are going to not care about collateral damage, and may
very well send a clear message by blocking TLS 1.3.

I would love to have a nice, simple, censorship resistance
improvement. Maybe there is low-hanging fruit we missed. It's worth
still thinking about. But at this moment I don't see a useful way to
achieve the goal.

Sincerely,
Watson Ladd

>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin