On Tue, 14 Feb 2017, Ben Schwartz wrote:
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.
This seems like a bandaid to TLS that I think just needs
fixing in the TLS protocol.
If I was a passive attacker logging lots of traffic, I would just
query the SNI's of all major sites (and/or any other A/AAAA records
I encounter while monitoring the traffic streams) so the protection
this offers is lost very quickly.
I don't think the additional TLS to DNS "ephemeral SNI" synchronisation
is worth the trouble. It would make more sense to have the TLS
client take the hit of some additional roundtrip to the server to
convey this privately after the EDH.
Also, it would make more sense to actually use the TLS server PUBKEY
for this, if the server uses the same pubkey for a lot of certificates
or SubjectAltNames. It is just as meaningless to the observer as an
ephemeral SNI, but now the TLS server can select the proper key if
it is configured with multiple different keypairs.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
