I wrote a similar draft a few years ago which I've been considering
resurrecting if there is interest:
https://tools.ietf.org/html/draft-nygren-service-bindings-00
One of the big challenges that at least in the web context, browsers want
to make as few DNS lookups as possible prior to making HTTP requests.
(For example, some home gateways choke if too many requests are
outstanding.)
Having to lookup both A and AAAA is already a problem. So if we're going
to add
something, ideally we'd add something that was extensible that could be
used
for multiple purposes.
For this case, the result could be something like:
_https._b.www.example.com IN B 2 0 www.example.com. { "alpn": "h2",
"tls-sni": "SOME_TOKEN", "hsts": true }
_https._b.www.example.com IN B 1 0 www-alt.example.com. { "alpn":
"quic352", "tp": 443, "tls-sni": "SOME_OTHER_TOKEN", "hsts": true }
By adding this one single lookup, you both get to specify an alternate SNI,
be able to force HTTPS-only, and specify Alternative Services (ala rfc7838
but allowing it to be done in DNS). Having an extensible model here also
increases
the value of a client doing the lookup as once the records exist other
optional
attributes can be added in.
(Ignore the specific key/value pair examples in that expired I-D. They
made more
sense when some other things were being considered.)
Based on our extensive discussions in the TLS WG over the past few years,
introducing something like this into the DNS to indicate an alternate SNI
value
(which might be one shared with many other hostnames) or telling the client
not to send an SNI value seemed to be one of the best ways to help with
the SNI privacy problems, at least once there is a DNS privacy path.
For example, for a cert like *.example.com (perhaps with lots of other SANs
as well)
there is no reason the client needs to send "
something-potentially-private.example.com" when sending
an SNI value of "wildcard.example.com" would do just fine. The TLS
handshake
is too late to learn this, but if we could move it into the DNS then clients
could learn it (and potentially other useful info) before connecting.
[I added DKG as he was a strong advocate of doing something in this space
for signalling TLS SNI omission, alteration, or aliasing in DNS records.]
Erik
On Fri, Feb 17, 2017 at 3:49 PM, Ben Schwartz <bem...@google.com> wrote:
> Thanks for the input everyone! Here's an updated version with some
> clarifications based on your feedback:
> https://tools.ietf.org/html/draft-schwartz-dns-sni-02
>
> Diff:
> https://www.ietf.org/rfcdiff?url1=draft-schwartz-dns-sni-
> 01&url2=draft-schwartz-dns-sni-02
>
> I know this approach is controversial, so I'm also very curious to hear
> any suggestions of other ways that we could fix this privacy leak without
> slowing down everyone's connections. As a friend put it: if everyone can
> see you're reading justinbieber.tumblr.com, "that defeats the whole point
> of HTTPS".
>
> On Tue, Feb 14, 2017 at 1:02 PM, Ben Schwartz <bem...@google.com> 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
>>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
