On Sun, Mar 8, 2015 at 4:05 PM, Shumon Huque <[email protected]> wrote: > > Besides SNI, the subsequently presented server certificate is likely to > leak the website's identity also, so a larger scope encrypted handshake is > needed. I would prefer the TLS working group solve this problem > independently of DPRIVE. If TLS (for applications) needs bootstrapping > information from the content of signed DNS records (e.g. to provide better > resistance against active adversaries), they could obtain them over DPRIVE > developed protocol extensions. >
That is what I want to happen as well. What worries me is if we build a circular dependency into the stack. TLS is layered on top of DNS at several points. The names used in TLS are DNS names. If we build a dependency on TLS into DNS then we end up with a death embrace that locks the two protocols together in a fashion that makes later cruft clearance impossible. > Also I'm not sure it's worth the effort to protect the identity of only > websites that are colocated with many others on a shared hosting service. > If users want to not the leak the identity of websites they visit, a more > general solution is needed that covers other sites too (how would a user > know in advance in any case if the website is on a shared host?). This > means looking at solutions that hide the network layer identity of the > service also, like Tor or other anonymity networks. > The place where we get a short term payoff is for enterprise networks where the resources being accessed are in a part of the DNS name space that is not visible to the general Internet. But the co-loc sites are still very important. Going to a big site like Facebook is not usually a privacy issue. And when it is a privacy issue you need mechanisms like Tor to get a connection. Its when you go to a smaller site that is more likely to be co-loc that more privacy issues arise. > > Also keep in mind that DPRIVE has a very limited initial charter ( > https://datatracker.ietf.org/wg/dprive/charter/ ), focussing initially > only on stub to iterative-resolver confidentiality (and only a later stage > covers confidentiality to authority servers). > Having a small initial charter is not license to create unnecessary problems later on.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
