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

[Richard Barnes <[e-mail]>]

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 <[e-mail]> wrote:

>
> On 7 Feb 2017, at 18:12, Ben Schwartz <[e-mail]> 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 <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>