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

From: Ben Schwartz <[email-masked]>
Date: Tue, 7 Feb 2017 11:12:12 -0500

Hi TLS,

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.

Thanks,
Ben Schwartz

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Feb 2017 18:48:53 +0200

> change based on your input.

What is the reason for treating IPv6 and IPv4 differently? AFAIK, The
way clients usually deal with IPv6, splitting will not work properly.

I didn't see definition of the wire format of the record, or if it
is RFC3597-compliant[1] (all new rrtypes SHOULD be RFC3597-compliant).

I earlier had an idea for doing siminar thing via DNS records and a new
SNI name type (with just a few bytes of space). The problematic practice
with SNI was sending multiple name types, not using new name types with
servers declaring support.

[1] Basically means that authoritative servers, recursive reolvers,
DNS caches, DNS forwarders and stub resolvers can all handle the
data part as opaque data, not having to modify it in any way.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Feb 2017 17:13:06 +0000

I read the doc.  I’m a little dumb, but I think a more expanded ladder diagram for Figure 2 would have helped me.

The basic process is query DNS, get the SNI record value, and use that as the SNI value when connecting to the domain, right? But I’m not sure of the interaction of CNAME entries here.  Do you keep the SNI value in the first, or does cname-chasing erase/override the initial value?

And does this really provide much additional privacy?  Can’t the attacker/repressor also do DNS queries and figure it out?  There should probably be some text around that issue.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 7 Feb 2017 14:11:51 -0500

> way clients usually deal with IPv6, splitting will not work properly.

I proposed to treat IPv4 and IPv6 separately because a "dual stack" domain
owner might reasonably have very different configurations for their IPv4
and IPv6 servers.  For example, a domain owner might use shared hosting for
IPv4, but assign each domain to a unique IPv6 address.  Splitting the DNS
record in this way allows the server operator to disable SNI (by publishing
an SNI record with empty RDATA) for connections to the IPv6 servers,
without affecting requests to the IPv4 servers.

You raise a good point: this requires a dual-stack client to be able to
generate different ClientHello messages for IPv4 and IPv6 servers during
Happy Eyeballs.  If that's impractical, then we can remove this split, and
just be a little less flexible for "dual stack" server operators.  Does
anyone know whether it's reasonable for clients to generate ClientHello
messages that depend on IPv4 vs IPv6?

> is RFC3597-compliant[1] (all new rrtypes SHOULD be RFC3597-compliant).

Thanks for the pointer.  It should definitely be RFC 3597 compliant.  I'll
clarify that in the next version.

> servers declaring support.

OK.  For now I don't see a reason to switch to a new name type, but having
an SNI record might allow us to do so in the future (see the Extensibility
section).

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 7 Feb 2017 14:33:17 -0500

On Tue, Feb 7, 2017 at 12:13 PM, Salz, Rich <[email-masked]> wrote:

> I read the doc.

Thanks!

>   I’m a little dumb, but I think a more expanded ladder diagram for Figure
> 2 would have helped me.
>

OK.  I think I included all the packets.  Is it unclear what each packet
is?  Did I miss some?  Or would like you more explanation about what each
endpoint is "thinking" at each step?

> The basic process is query DNS, get the SNI record value, and use that as
> the SNI value when connecting to the domain, right?
>

Yep, that's the whole idea in one sentence.

> But I’m not sure of the interaction of CNAME entries here.  Do you keep
> the SNI value in the first, or does cname-chasing erase/override the
> initial value?
>

I wasn't intending any special interaction with CNAME, and (therefore) no
CNAME chasing unless someone specifically CNAMEs _443._tcp.foo.example.com.
So yes, you would keep the SNI value at the specified name.  (DNAME would
cause chasing.)  Does that seem reasonable?

> And does this really provide much additional privacy?
>

The examples section says

   A host that serves many subdomains with a single wildcard certificate
   could set the SNI of all subdomains to the same fixed subdomain, in
   order to prevent a passive adversary from learning which subdomain a
   user is accessing.

I think that's a worthwhile benefit that would help real users today.

> Can’t the attacker/repressor also do DNS queries and figure it out?  There
> should probably be some text around that issue.
>

The section on optimizing privacy says:

   If the adversary has full knowledge of the contents of the global DNS
   (a strong adversary), then users of a domain only experience a
   privacy benefit if another domain at the same IP address uses the
   same SNI RDATA.  The privacy benefit increases as more domains share
   the same SNI RDATA and the same IP addresses.

What else would you like to see?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Feb 2017 15:14:42 -1000

On 2/7/2017 9:11 AM, Ben Schwartz wrote:

> ...
>
> I proposed to treat IPv4 and IPv6 separately because a "dual stack"
> domain owner might reasonably have very different configurations for
> their IPv4 and IPv6 servers.  For example, a domain owner might use
> shared hosting for IPv4, but assign each domain to a unique IPv6
> address.  Splitting the DNS record in this way allows the server
> operator to disable SNI (by publishing an SNI record with empty RDATA)
> for connections to the IPv6 servers, without affecting requests to the
> IPv4 servers.
>

I am not sure that this is the right trade-off. If some adversary
censors based on the SNI, they will also be able to censor based on the
IP address of the server (v4 or v6). The resistance to censorship (or
monitoring) only happens if the connections are proxied through another
service. I would think that you want the name of that proxy service in
the DNS, independently of the network configuration.

-- Christian Huitema

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Feb 2017 02:49:22 +0000

> I think that's a worthwhile benefit that would help real users today.

And then the server trusts the Host header?  That probably works if the server has a definitive list of the hosts it serves.  But do not that there can be issues with "just trusting" the Host header.  For example, in a CDN you need to make sure that you don't become an open proxy.  

But I do think that this might be the most likely privacy benefit -- aggregation into a larger anonymity set -- and should be up earlier in the document, or at least telegraphed :)

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 7 Feb 2017 22:20:28 -0500

On Tue, Feb 7, 2017 at 8:14 PM, Christian Huitema <[email-masked]>
wrote:

> I am not sure that this is the right trade-off. If some adversary censors
> based on the SNI, they will also be able to censor based on the IP address
> of the server (v4 or v6). The resistance to censorship (or monitoring) only
> happens if the connections are proxied through another service. I would
> think that you want the name of that proxy service in the DNS,
> independently of the network configuration.
>
> -- Christian Huitema
>

I agree: against "knowledgeable" adversaries, moving services onto separate
IPs hurts instead of helping, so my example isn't great motivation.  Based
on your and Ilari's feedback, I'll probably remove the v4/v6 split unless
we can come up with a more attractive version.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Feb 2017 09:12:59 +0200

On 7 Feb 2017, at 18:12, Ben Schwartz <[email-masked]> wrote:

> Hi TLS,
> 
> 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 <https://tools.ietf.org/html/draft-schwartz-dns-sni-00>
> 
> Please read and critique!  This is a starting point; the contents will change based on your input.

Hi, Ben

I’m a little surprised that you depend on RFC 7858 (DNS over TLS), which is fairly new and lightly deployed, but do not depend on DNSSEC, which is (slowly) getting traction.

If you assign a one fake SNI to each real name, then a determined adversary (especially the police state) can map the fake SNIs for all domains of interest and you lose the privacy.

If you assign one fake SNI for a bunch of real names, then the best an adversary can do is to associate a visible SNI with a group of names, some of which may be innocuous. But I’m thinking, why do we need SNI at all in the TLS handshake?  Obvious answer is to select the right certificate, but under this scenario the certificate already has to have the names of all domains possibly hosted on the server.

So why not instead use secure delegation using signed CNAME records and a new record (which perhaps should be called “noSNI”). Then the diagram looks like this:

  DNS Server                      Client                      TLS Server
     |                               |                                 |
     |<===example.com AAAA?==========|                                 |
     |<=_443._tcp.example.com NOSNI?=|                                 |
     |=example.com CNAME a7.cdn.net=>|                                 |
     |==a7.cdn.net AAAA 2001:db8::1=>|                                 |
     |==example.com NOSNI cdn.net===>|                                 |
     |                               |--------------TCP SYN----------->|
     |                               |<------------TCP SYN+ACK---------|
     |                               |--------------TCP ACK----------->|
     |                               |------ClientHello SNI:none------>|
     |                               |<--------- ServerHello ----------|
     |                               |<-- Certificate name:cdn.net ----|

And the server works it out using the HOST header as Rich said.  Of course this depends heavily on DNSSEC validation, but it would work with any version of TLS.

Yoav

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 Feb 2017 09:06:12 -0500

For me, the main drawback here (besides the futuristic assumptions), is the
continued reliance on the DNS infrastructure.  Even when using TLS, the DNS
is architecturally hostile to privacy, e.g., due to resolvers operated by
ISPs or the client subnet extension.

I'm sympathetic to the desire to get SNI off the wire or render it
meaningless, but much more interested in solutions where information about
reachability flows over paths that align with application-layer
relationships (vs. lower layers), since these tend to align better with the
parties that an endpoint already has to reveal its interests to.

For example, the proposed HTTP ORIGIN frame [1] allows a web server to
declare itself available to serve origins other than the one the client
connected to, so that the client doesn't have to initiate new TLS
connections for those origins.  That doesn't eliminate the SNI problem, but
it can reduce it in some cases by a couple orders of magnitude.

--Richard

[1] https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-01

On Wed, Feb 8, 2017 at 2:12 AM, Yoav Nir <[email-masked]> wrote:

> I’m a little surprised that you depend on RFC 7858 (DNS over TLS), which
> is fairly new and lightly deployed, but do not depend on DNSSEC, which is
> (slowly) getting traction.
>
> If you assign a one fake SNI to each real name, then a determined
> adversary (especially the police state) can map the fake SNIs for all
> domains of interest and you lose the privacy.
>
> If you assign one fake SNI for a bunch of real names, then the best an
> adversary can do is to associate a visible SNI with a group of names, some
> of which may be innocuous. But I’m thinking, why do we need SNI at all in
> the TLS handshake?  Obvious answer is to select the right certificate, but
> under this scenario the certificate already has to have the names of all
> domains possibly hosted on the server.
>
> So why not instead use secure delegation using signed CNAME records and a
> new record (which perhaps should be called “noSNI”). Then the diagram looks
> like this:
>
> *  DNS Server                      Client                      TLS Server*
> *     |                               |                                 |*
> *     |<===example.com <http://example.com> AAAA?==========|
>                   |*
> *     |<=_443._tcp.example.com <http://tcp.example.com> NOSNI?=|
>                       |*
> *     |=example.com <http://example.com> CNAME a7.cdn.net
> <http://a7.cdn.net>=>|                                 |*
> *     |==a7.cdn.net <http://a7.cdn.net> AAAA 2001:db8::1=>|
>                   |*
> *     |==example.com <http://example.com> NOSNI cdn.net
> <http://cdn.net>===>|                                 |*
> *     |                               |--------------TCP SYN----------->|*
> *     |                               |<------------TCP SYN+ACK---------|*
> *     |                               |--------------TCP ACK----------->|*
> *     |                               |------ClientHello SNI:none------>|*
> *     |                               |<--------- ServerHello ----------|*
> *     |                               |<-- Certificate name:cdn.net
> <http://cdn.net> ----|*
>
> And the server works it out using the HOST header as Rich said.  Of course
> this depends heavily on DNSSEC validation, but it would work with any
> version of TLS.
>
> Yoav
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 8 Feb 2017 10:57:44 -0500

> (slowly) getting traction.

To be clear, the draft only depends on RFC 7858 for privacy, not integrity,
against a "near" adversary who otherwise could learn the sensitive
information by watching the client's DNS queries.  Against that adversary,
your proposal here would also need RFC 7858.  Against a "far" adversary who
can only see traffic to the TLS host, neither proposal needs RFC 7858.

If you assign a one fake SNI to each real name, then a determined adversary
> (especially the police state) can map the fake SNIs for all domains of
> interest and you lose the privacy.
>

I agree.

> this depends heavily on DNSSEC validation, but it would work with any
In the scenario where "the certificate already has to have the names of all
domains", I think the draft already covers this without DNSSEC.  The server
operator can just set an SNI record with empty RDATA for _443._
tcp.example.com, indicating to the user that they should omit SNI.

The case where we would need DNSSEC is if the default certificate _doesn't_
include example.com.  I agree that supporting such cases would be good, but
I don't think the marginal benefit justifies restricting the whole feature
to only clients that do DNSSEC validation.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 8 Feb 2017 11:28:07 -0500

On Wed, Feb 8, 2017 at 9:06 AM, Richard Barnes <[email-masked]> wrote:

> For me, the main drawback here (besides the futuristic assumptions), is
> the continued reliance on the DNS infrastructure.  Even when using TLS, the
> DNS is architecturally hostile to privacy, e.g., due to resolvers operated
> by ISPs or the client subnet extension.
>

I agree, which is part of why I'm very interested in DNS over HTTP [2] (but
I think that's off-topic for this list).

> it can reduce it in some cases by a couple orders of magnitude.

Yeah, I'm also very excited about HTTP ORIGIN, TLS Post-Handshake Auth [3],
and anything else that lets us reuse our TLS tunnel for the most different
stuff.  However, I think these proposals are actually very complementary.
The SNI record improves privacy on the initial connection to a server; HTTP
ORIGIN improves privacy on subsequent connections to the same server.
Together, they can make it so the SNI (1) is not proof of anything on its
own and (2) is too infrequent for strong statistical attacks.

[2] https://tools.ietf.org/html/draft-hoffman-dns-over-http-01
[3] https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00

>> 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:
>> And the server works it out using the HOST header as Rich said.  Of
>> course this depends heavily on DNSSEC validation, but it would work with
>> any version of TLS.
>>
>> Yoav
>>
>>
>>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Feb 2017 12:48:19 -0500

Thanks for the feedback everyone!  I've incorporated your suggestions and
made a new version:
https://tools.ietf.org/html/draft-schwartz-dns-sni-01

Diff:
https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-00&url2=draft-schwartz-dns-sni-01