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

[Ben Schwartz <[e-mail]>]

On Tue, Feb 7, 2017 at 11:48 AM, Ilari Liusvaara <[e-mail]>
wrote:

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


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

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


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

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


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