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

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote:
> 
> You don't understand the purpose of SNI and how the (already weak)
> rfc2818 section 3.1 server endpoint identification and CABrowser Forum
> public CA Domain validation has been designed to work.

SNI has extremely little to do with public CA domain validation,
except for special validation certificate selection in some
methods.

Out of 10 standard methods, only 2 would encounter any problems at all
if SNI didn't work (test certificate and random value via certificate).

And methods using these two presumably both use SNI and don't map
it. Certainly, the only known instantiations of "random value via
certificate", which are the TLS-SNI validations from ACME specify
SNI to be sent. And the values it sends are permanently NXDOMAIN in
DNS.

And RFC2818 preceedes SNI by about three years, so it can not have
been designed to rely on SNI.

> Wordpress.com isn't using SNI at all, so the ultimate solution
> would be for the client to entirely omit SNI from ClientHello.
> 
> wordpress itself could achieve just the same by using URLs
> of the kind
> 
>    blogs.wordpress.com/blogname with a cert issued to blogs.wordpress.com
> 
> rather than
> 
>    blogname.wordpress.com with a cert issued to *.wordpress.com

Nope. That proveds no isolation between blogs. So any way to compromise
one would compromise them all.

With separate host per blog, you at least avoid the undefendable cross-
blog exploits. You still have the cookie exploits, but those can be
defended against. And if one adds the base domain to PSL (e.g. like
Blogspot (Google)) one doesn't have cookie exploits either.

> Btw. your adversary will see the cleartext DNS lookup prior to the
> TLS handshake, and tell accesses to multiple different blogs apart by
> looking at the size of the responses.

DNS over TLS (TCP/853). EDNS0 padding. Both have PS RFCs.


-Ilari