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 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). 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. [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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
