Re: [DNSOP] Proposal for a new record type: SNI

[Ben Schwartz <[e-mail]>]

On Tue, Feb 14, 2017 at 2:16 PM, Robert Edmonds <[e-mail]> wrote:

> Ben Schwartz wrote:
> > Hi dnsop,
> >
> > I've written a draft proposal to improve the privacy of TLS connections,
> by
> > letting servers use the DNS to tell clients what SNI to send.
> >
> > https://tools.ietf.org/html/draft-schwartz-dns-sni-01
> >
> > I've incorporated some helpful feedback [1] from the TLS WG, but now I
> > could use your help analyzing the DNS side. All comments welcome; this
> > draft will change based on your feedback.
> >
> > One particular issue that I could use advice on: should this be a new
> > record type, or should it reuse/repurpose an existing type like SRV or
> PTR?
> >
> > Thanks,
> > Ben
> >
> > [1] https://www.ietf.org/mail-archive/web/tls/current/msg22353.html
>
> Hi, Ben:
>
> I'm kind of curious: your examples are pretty HTTP-centric, and HTTP
> already has some pretty strong features for origins to persistently
> modify how clients perform TLS, i.e., HTTP Strict Transport Security and
> HTTP Public Key Pinning, along with preloading of those settings by the
> browser vendors. Why not follow that same model for the functionality in
> your draft?
>
> --
> Robert Edmonds
>

Hi Robert,

While this technique would apply to any use of TLS, you're right that I'm
mainly motivated by improvements for HTTPS.

It's true, we could accomplish something like this by preloading a data
file into browsers.  In some sense, this is also true for any aspect of
DNS!  Obviously, preloading fares very badly when the data in question is
valid for short times, or applies to many thousands or millions of domains,
and I think both problems apply here.

For example, a CDN that operates DNS on behalf of its customers could apply
SNI records to all of their domains.  Preloading all of those domains into
every browser seems impractical, and the list will quickly become outdated.

Without preloading, we cannot solve the problem of revealing the
destination in the initial connection.

I would also note that HSTS and HPKP could not have been implemented using
insecure DNS, given their adversary model.  The SNI record is very
different, and does not require DNSSEC.

--Ben