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

On Wed, Feb 15, 2017 at 6:10 PM, John Levine <johnl@taugh.com> wrote:

> >I'm /soooo/ not a TLS person, but I think that this was discussed in
> >the TLS WG and didn't make it into the final spec -- it requires (at
> >least) an additional RTT. You do get SNI encryption with Zero-RTT, but
> >it's too later by then...
> >Some slideware: https://www.ietf.org/proceedings/94/slides/slides-
> 94-tls-8.pdf
> >The DNS SNI lookup could at least be done in parallel with the
> >"normal" DNS one (and, possibly returned in a
> >draft-wkumari-dnsop-multiple-responses answer :-))
>
> To put it baldly, if it is a problem that SNI leaks, the solution is
> to fix SNI.  This is not a solution, it is at most a band-aid that
> will deter a subset of unsophisticated snoops while adding useless
> complexity to https.  For example, what are users supposed to do when
> the SNI DNS records and the SNI mapping in the servers inevitably get
> out of sync?
>

FWIW, the draft recommends users retry with whatever their behavior would
have been otherwise, effectively imposing a one roundtrip penalty in this
failure case.

> "But fixing SNI is hard" isn't a good reason to do this.  I understand
> that adding an extra round trip to the handshake would be a problem,
> but I am a long way from believing that's the only way to fix SNI.
>

Removing SNI without adding an extra roundtrip to every SSL connection
logically requires the client to learn an additional piece of information
about the server before it contacts the server.  In a typical situation
(e.g. hyperlink following), the client's only initial piece of information
about the server is its domain name.

Mapping a domain name to information about the thing that lives at that
domain name is the defining characteristic of the DNS.  It seems to me,
therefore, that any solution to the SNI problem must either use DNS or
reinvent DNS.  I'd prefer the former.

There are certainly alternative ways that we could use DNS (e.g. publishing
a public key).  Of the available options, I felt this was the simplest.  I
think it could reasonably be extended to a more sophisticated solution if
one were developed.

>
> R's,
> John
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>