On Sun, Mar 8, 2015 at 12:14 PM, Phillip Hallam-Baker <[email protected] > wrote:
> > > On Sat, Mar 7, 2015 at 8:47 PM, Shumon Huque <[email protected]> wrote: > > > The simplest way of addressing this issue is not using the TLS SNI >> extension. >> > > You are arguing against SNI on the DNS resolver, which isn't the point. > The problem comes on the application server, e.g. Web server that is > discovered. > > IPv4 will continue to be essential on Web servers for at least 20+ years > for backwards compatibility. And IPv4 addresses will continue to appreciate > in cost for the next ten years or so. When an IPv4 address is costing > $50/year to an ISP, the cost of non-SNI TLS is going to add about a hundred > dollars a year to server operation costs. > > The reason this is strongly connected to DPRIV is that the decisions we > make will determine whether DPRIV helps us solve these other problems or > becomes an additional barrier to deployment. > 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. 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. This might be where we are heading anyway - Facebook is already available as a Tor hidden service for example, and I'm sure others will follow. With something like Tor, you already gain encryption of the the cleartext TLS handshake parameters, ahead of any TLS protocol changes. Of course, you'd have to consider active attempts to de-anonymize users (malicious guard/entry nodes etc), but I think research is going on in this area. 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). I agree that we should not be an impediment to better TLS privacy mechanisms (and I support TLS enhancements to more fully encrypt cleartext handshake parameters), but I don't think DPRIVE needs to actively help solve this problem for TLS either. Shumon Huque. > > If we want people to use DPRIV we had better design it in a way that makes > it as small as possible with as few dependencies as possible. > > > I don't expect operators to deploy TLS/DNS instances on the same system >> that houses 200 other websites, and even if they did, they would likely not >> be sharing the same application port. >> > > SNI is used on the Web servers that the DNS services provide discovery to. > The way to close up the SNI gap is to encrypt the initial handshake. But to > make that possible you have to get a key from somewhere to start the > conversation. > > In this case the key is a host key and not a service key. So if I have > web1.com, web2.com on host1.coloc.net the discovery sequence for web1.com > would be: > > web1.com XSRV -> host1.com + key (host1.coloc.net) > > host1.coloc.net TLS handshake under key (host1.coloc.net) > Turn on encryption > Send SNI for web1.com > > Get cert for web1.com. > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
