On Sat, Mar 7, 2015 at 8:47 PM, Shumon Huque <[email protected]> wrote:
> On Sat, Mar 7, 2015 at 1:43 PM, Phillip Hallam-Baker < > [email protected]> wrote: > >> I have been thinking about the TLS SNI hole again and I have a sketch >> that I think is quite practical for solving the issue. >> >> For the sake of argument, assume we are doing a TLS/2 which is a complete >> break with the past TLS protocol that removes most if not all the options >> in the current protocol and either eliminates them or makes them mandatory. >> > > Is that what we are envisioning, and if so, why? I was assuming we are > planning to reuse an existing TLS protocol (v1.2 or the upcoming 1.3). > People have been discussing TLS/2 in the TLS working group. My point is that if we layer DNS/2 on TLS then we end up with all the legacy crud from TLS/1.2 permanently baked into the stack. What IETF should be trying to move towards is a state where we can jettison as much legacy cruft as possible when we move to IPv6. Crud tends to build up over time. > So no more OCSP stapling option, if you are doing TLS/2, it is a >> requirement. The restart mechanism is MTI as well and has a mechanism to >> allow the crypto state to be offloaded to the server. >> >> >> One hole that does raise privacy issues is Server Name Identification. If >> you have 200 web sites on a server, you don't want to have to burn an IPv4 >> address for each one. So the DNS name of the server has to be passed in the >> TLS handshake before the encryption tunnel is established. That is a >> privacy hole. >> >> There are a few ways round this problem. But all the best ones involve >> passing some sort of key from the DNS server. But to make those work >> cleanly it is essential that TLS is layered on DNS and not the other way >> round. >> > > > 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. 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
