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

From: [email-masked] (Martin Rex)
Date: Thu, 9 Mar 2017 11:52:07 +0100 (CET)

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.

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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Mar 2017 20:26:13 +0100

> It is formally provable that there is no solution to the problem

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?

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Mar 2017 09:25:41 +0100 (CET)

Ben Schwartz wrote:
> Martin Rex <[email-masked]> wrote:
> 
>>Ben Schwartz 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.

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

You might want eventually want to check with the logging functionality
of Adblockers (such as uBlock) or browser plugins like "Collusion", to how
many different servers & domains a typical server (including *.wordpress.com)
publishes (HTTP-Referer) where the user just went.

The decision to register a distinct & seperate name in DNS is an explicit
and obvious desire to **PUBLISH** this information.  If you do not want
to publish information, DO NOT REGISTER it in the DNS, so that it will
and it will never appear in SNI, in DNS lookups, or in DV-validation
request for obtaining a TLS server cert from a public CA.

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.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 13:17:32 +0200

> 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.

>    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.

> looking at the size of the responses.

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

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Mar 2017 13:33:14 +0100 (CET)

> except for special validation certificate selection in some

SNI is the TLS-standard for clients to tell the server

"This is the DNS-Hostname, which I will use for rfc2818 section 3.1
 server endpoint identification. If you have multiple server certificates
 to choose from, you may want to consider this SNI value for choosing
 the server certificate to use for this TLS handshake".

CABrowser-Forum defines the rules which browsers implemenent on
top of rfc2818 section 3.1 server endpoint identity checks
of server certificates.

btw. SNI explicitly excludes IPv4 and IPv6 address matching that
is defined in rfc2818 section 3.1 as alternatives to DNS Hostname
matching.

-Martin

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 13:15:26 +0000

> top of rfc2818 section 3.1 server endpoint identity checks

This is neither accurate nor correct. The CA/Browser Forum neither
describes nor dictates browser behaviour.

Perhaps you are thinking RFC 6125, but since you've stated this multiple
times, I can only believe this is an honest mistake, but one that deserves
calling out.

> is defined in rfc2818 section 3.1 as alternatives to DNS Hostname

Could you clarify the relevance of this to the discussion? While it serves
as a useful reminder for those who may have forgotten, I'm at a loss as to
how this has any relevance or impact to the conversation thus far or the
discussion of tradeoffs, so I must be missing something quite basic.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Mar 2017 15:27:42 +0200

On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote:
> Hi TLS,
> While we're trying to figure that out, I think there's a simple trick that
> could help a lot: just let domain owners tell users an alternate SNI in a
> DNS entry.

Stumbled upon the following potential problem:

Suppose a server has certificate that is wider than what it needs
(wildcards anyone?) and it thinks SNI values are more trustworthy
than :authority/host (which this document seems to imply), then:

DNS spoof can point the A/AAAA records of some name certificate
is valid for to that server and set SNI records to some name that
this server accepts. Then visitor can open connection (since SNI
check and certificate check passes). And then server can respond
to queries for unknown vhost in rather dangerous ways.

E.g. Suppose victim.example.org has wildcard cert.

victim.example.org IN AAAA 2001:db8:1234:5678::ABCD

Attacker spoofs:

dangerous.example.org IN AAAA 2001:db8:1234:5678::ABCD
_443._tcp.dangerous.example.org IN SNI victim.example.org

Now if someone visits https://dangerous.example.org/, victim.example.org
will see SNI for itself, so it accepts the connection. The client
sees the *.example.org name, so it doesn't complain and sends the
request automatically. And then the first request will be for
https://dangerous.example.org/. Which can trigger unexpected behaviour,
potentially exploitable (the web security model is real fragile).

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Mar 2017 10:29:30 -0500

> On Feb 7, 2017, at 11:12 AM, Ben Schwartz <[email-masked]> 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.
> 
> While we're trying to figure that out, I think there's a simple trick that could help a lot: just let domain owners tell users an alternate SNI in a DNS entry.
> 
> Here's the full draft:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-00
> 
> If you just want to glance at it, I recommend Figure 2.
> 
> Please read and critique!  This is a starting point; the contents will change based on your input.

Instead of looking for a kludgey replacement SNI in DNS (that won't get deployed,
and provides rather weak obfuscation) it seems more sensible to publish keys in
DNS that make it possible to encrypt the entire client HELLO, SNI and all.

I do not think that the proposed SNI in DNS is worth doing.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 14 Mar 2017 03:34:25 -0400

> DNS that make it possible to encrypt the entire client HELLO, SNI and all.

+1