Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Nick Mathewson <[e-mail]>]

On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich <[e-mail]> wrote:
> We discussed this before.  Not that we can't discuss it again.  Here's a link to slides I presented at the Toronto Interim in July 2015.
>
>         https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing
>


Thanks for that link, Rich!

Please forgive me if my analysis has already been gone over, but I
believe that there are at least three problematic aspects in the
argument as presented in your slides.

1) Entrenchment of codependent vulnerabilities

This is a strong antipattern in security design, and it's been
practiced by some of the great minds of the field, but I think it's
fundamentally mistaken. Here's how it works:

There are two systems, A and B.  Each has a problem that enables some
kind of attack. The people who maintain system A say: "There is no
point in fixing A, because any attacker who breaks A could achieve the
same results via B."  But the people who maintain system B say: "There
is no point fixing B because any attacker who breaks B can achieve the
same results via A."

Both groups are using solid logic: neither one of them would
materially improve user security by fixing the vulnerability in their
system.  The Codependent Vulnerability antipattern arises when no
progress is ever made, because each group decides that the problems
outside its control will probably never be fixed.

In your slides, I see several instances of codependent vulnerabilities:

a) Improved DNS security vs Encrypted SNI

The lack of security in current DNS usage is taken to justify not
improving SNI privacy. But in discussions about DNS privacy,
vulnerabilities in other protocols are frequently taken as
justification for not improving DNS privacy.

b) Traffic analysis vs encryption

Traffic analysis is indeed strong today, but it's not omnipotent, and
good research on resisting it is happening all the time.  But if we
take the weaknesses of TLS against traffic analysis a a permanent
feature of the world, then such research will have less opportunity to
bear fruit, since TLS will entrench the problems that
anti-traffic-analysis research cannot yet solve.

c) Technical attacks vs rubber-hose attacks

See point 2 below.


2) Attacks are not equally costly and do not scale equally well.

It's not sufficient to say "This defense will not render the attack
impossible; therefore it is useless"; we also need to consider whether
the defense will render the attack _more expensive_.

Even for regimes unconcerned with fair play and regimes with
significantly intrusive attitudes to civil liberties... intimidating
citizens, applying political pressues, and backdooring infrastructure
are not zero-cost operations.  In nearly all cases, ithese attacks are
more difficult and costly than simply reading bytes off the wire.


3) Censorship vs surveillance.

The analysis in the slides is concerned with attackers against privacy
rather than attackers against availability.  But IMNSHO, both kinds of
attacker are a significant threat to human rights.

Unencrypted SNI makes a censor's job extremely easy.  In today's TLS,
it's trivial to block targeted domains hosted at a provider without
blocking ones where the censors consider access desirable.  Encrypting
SNI would make this kind of blocking more difficult and technically
expensive.


To be fair, encrypted SNI would probably make trouble for providers
who host some censored and some uncensored services.  Plaintext SNI
does make it easier for censors to be selective, and thereby makes it
easier for hosting providers to avoid conflicts and drama.


best wishes,
-- 
Nick Mathewson
<[e-mail]>