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

[Dave Garrett]

On Friday, March 10, 2017 10:29:30 am Viktor Dukhovni wrote:
> 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.

+1

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> On Feb 7, 2017, at 11:12 AM, 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.
> 
> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz 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.

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/ 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  2001:db8:1234:5678::ABCD

Attacker spoofs:

dangerous.example.org IN  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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ryan Sleevi]

On Fri, Mar 10, 2017 at 7:33 AM Martin Rex  wrote:

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


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.

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


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.

>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Ilari Liusvaara wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Ben Schwartz wrote:
> Martin Rex  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?

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Richard Barnes]

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  wrote:

>
> On 7 Feb 2017, at 18:12, Ben Schwartz  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
>
> 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.
>
>
> 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  ?==|
>   |*
> * |<=_443._tcp.example.com  NOSNI?=|
>   |*
> * |=example.com  CNAME a7.cdn.net
> =>| |*
> * |==a7.cdn.net   2001:db8::1=>|
>   |*
> * |==example.com  NOSNI cdn.net
> ===>| |*
> * |   |--TCP SYN--->|*
> * |   | * |   |--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
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

On 7 Feb 2017, at 18:12, Ben Schwartz  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 
> 
> 
> 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.

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 ?==| |
 |<=_443._tcp.example.com NOSNI?=| |
 |=example.com CNAME a7.cdn.net=>| |
 |==a7.cdn.net  2001:db8::1=>| |
 |==example.com NOSNI cdn.net===>| |
 |   |--TCP SYN--->|
 |   ||
 |   |--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




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz 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
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls