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). 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. 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. Last I heard, the TLS/DNS proposals are using port 53 or an alternate non-web port. In such configurations, we don't need SNI to disambiguate the application service endpoint on a shared system. Also, is protecting the identity of the nameserver one of the privacy goals? This will be very challenging to do, unless we do something radical like making them Tor hidden services or similar. A passive surveillance adversary collecting packets can pull out the IP address of the nameserver easily enough, and if they wanted the NS name, correlate it with a passive DNS database. Besides SNI, the TLS server certificate, transmitted in the clear in the handshake, could also reveal the nameserver identity, so we'd also have to consider if that needs to be protected or obfuscated. It would be nice if the SNI extension supported subject name forms other than "hostname", but it doesn't today. If so, one could define a new nametype carrying an obfuscated identity/key/token if needed. Shumon Huque
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
