In article <cahbrmsa278usgfnzxhrsls6_efxpemoakn65ec0yhcw93ok...@mail.gmail.com> you write: >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.
I have problems with the word "other". This approach depends for its security on the assumption that it is hard to reverse SNI record lookups, that is, to find the qname(s) that have SNI records with given contents. That is a poor assumption. There are many large passive DNS databases, and a lot of people have access to them. My working assumption is that anyone sophisticated enough to peek at TLS handshake packets is sophisticated enough to find a passive DNS source. So to me the question is whether the small speculative incremental increase in user security is worth the investment to define a new record type, add it to DNS servers and provisioning systems, add it to web server configuration languages, and set up whatever infrastructure is needed to coordinate the published SNI records and what the web servers expect. I'd also note that if the assumption is that people will publish SNI records through the usual registrar and dns hosting operators managed through web consoles, there is no chance that the webware will support SNI records. We know this because they don't support any other RRTYPEs defined in the past decade, either. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
