Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

[David Fifield <[e-mail]>]

On Tue, Feb 19, 2019 at 11:04:06PM +0300, Dmitry Belyavsky wrote:
> Please take a look at an initial submission of the draft.
> The draft describes a Fake SNI mechanism intended to cheat DPI systems in
> a case 
> when a DPI system blocks the connection if ESNI is present.
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Tue, Feb 19, 2019 at 10:43 PM
> Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt
> To: Dmitry Belyavskiy <[e-mail]>
> 
> Abstract:
>    The document provides a specification of the Fake Server Name
>    Indication.  Being implemented, the Fake SNI specification provides a
>    way to work around the monitoring solutions without providing any
>    additional information to external observers.

I initially viewed this proposal negatively, but after thinking about it
more during Dmitry's talk today (https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-fake-sni-00),
I think there are ways in which it can make sense.

The reason I initially viewed it negatively was that it seemed to be a
naive attempt at addressing the "proxy distribution" problem--where you
have to somehow share secret information with your genuine users but not
let it fall into the hands of an adversary, with the challenge that you
don't have a secure way to distinguish genuine users from an adversary.
The draft acknowledges the challenge but, I think, treats it too
lightly, as for me it is the core consideration: "DPI solutions are able
to obtain the DNS _fakesni records as legitimate clients do." It's the
same problem you would face if you were to establish mirror sites to
mitigate blocking: how do you inform your users of the mirror sites'
URLs without also informing the adversary you're protecting against?
Another way way to think about it is: you have a large set of secret
tokens, and you want it so that *anyone* can discover one token, but
*no one* can discover all the tokens.

There's a fair amount of research on secure proxy distribution, but they
all work by imposing limits on the adversary, by leveraging trust
relationships among genuine users, tying discovery to real-world
resources, or some other method. Here is a selection of research:
	https://censorbib.nymity.ch/#Nasr2019a
	https://censorbib.nymity.ch/#Douglas2016a
	https://censorbib.nymity.ch/#Wang2013a
	https://censorbib.nymity.ch/#McCoy2011a
The Fake SNI draft's DNS discovery doesn't impose any significant
limits, so if there is only one or a few fake SNIs, I think the idea
won't work against an adversary that can afford to do continuous
polling, even if the set of fake SNIs is rotated frequently.

But if you ensure that each fake SNI value is distributed once and only
once, then I think the idea has some merit. Then, it doesn't help an
adversary to do its own polling, because any SNIs it discovers will
never be used by a legitimate client. It doesn't help if it blocks SNI
values that clients have been seen to use, because those values will not
be used again.

This all assumes trustworthy DNS, so an adversary can't see the SNI
you're about to use before you use it. And it also assumes some level of
colocation, or else there is nothing to prevent an intermediary from
blocking the IP address regardless of SNI. (The same observations apply
to ESNI as well as Fake SNI.)

However, even with one-time-use fake SNI values, the design still has a
problem with replay. The generic attack is described at
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-04#section-3.1.
The adversary observes a client using an SNI value, then makes its own
connection to the same server using the same SNI value. Now the
adversary knows what particular colocated service on the server the
client is accessing, and even if it cannot block the server entirely
(because of colocation), it can terminate that client's specific
connection. Perhaps the server can check for and reject reused fake SNI
values--but then it also needs to be the case that all (or at least
many) of the users of the server's colocated services use Fake SNI, not
just the ones who are trying to access the services the adversary would
like to block, or else you violate the "Do not stick out" criterion.