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 <ynir.i...@gmail.com> wrote: > > On 7 Feb 2017, at 18:12, Ben Schwartz <bem...@google.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
