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

[Ben Schwartz <[e-mail]>]

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

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.


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