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 > <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 AAAA?==========| |
|<=_443._tcp.example.com NOSNI?=| |
|=example.com CNAME a7.cdn.net=>| |
|==a7.cdn.net AAAA 2001:db8::1=>| |
|==example.com NOSNI cdn.net===>| |
| |--------------TCP SYN----------->|
| |<------------TCP SYN+ACK---------|
| |--------------TCP ACK----------->|
| |------ClientHello SNI:none------>|
| |<--------- ServerHello ----------|
| |<-- Certificate name: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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
