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: <internet-dra...@ietf.org> > Date: Tue, Feb 19, 2019 at 10:43 PM > Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt > To: Dmitry Belyavskiy <beld...@gmail.com> > > 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
