Re: [TLS] New Draft: Using DNS to set the SNI explicitly

[Ben Schwartz <[e-mail]>]

On Thu, Mar 9, 2017 at 11:52 AM, Martin Rex <[e-mail]> wrote:

> Ben Schwartz wrote:
> >
> > Like a lot of people here, I'm very interested in ways to reduce the
> > leakage of users' destinations in the ClientHello's cleartext SNI.  It
> > seems like the past and current proposals to fix the leak are pretty
> > difficult, involving a lot of careful cryptography and changes to clients
> > and servers.
>
> It is formally provable that there is no solution to the problem
> that you're describing.
>

Perhaps I'm not trying to solve the problem that you're thinking of?

Here's an example:
Wordpress.com uses HTTPS, with a wildcard certificate (*.wordpress.com) for
all its hosted blogs, which have domains of the form
myblogname.wordpress.com.  A passive adversary watching traffic to
Wordpress.com can currently determine which blog each client IP address is
accessing by observing the IP source address and the TLS SNI in the
ClientHello message.

With this proposal, if Wordpress were to set an SNI DNS record on each
subdomain, with empty RDATA, compliant clients would omit SNI when
contacting the Wordpress server.  Connections would still work fine, but
the passive adversary would no longer know which client is accessing which
blog.

Is there something wrong with this example that I am missing?

While you can come up with all kinds of fancy and complicated schemes
> that are sufficient to provide you the illusion that you're looking for,
> the best you can come up with, will *be* an illusion.  But some of
> those illusions will cause lots of pain for implementors and make
> the whole thing fragile and cause interop problems.
>
> The situation is pretty similar for the hiding of the ContentType
> in TLSv1.3 records.  It is formally provable that this can not provide
> value, but it make implementations harder and reliably break some
> existing stuff.
>
> -Martin
>