On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote: > On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote: > > On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote: > > > I respectfully disagree. That system requires tight coupling between the > > > TLS implementation and DNS. This is not something that facilitates TLS > > > deployment. We want more TLS/HTTPS deployment, not less. > > > > I completely understand why you'd disagree on these grounds. My argument is > > that whilst this does require a significant amount of coordination, it's a > > more productive route than just focusing on SNI encryption, which still has > > its own share of problems. (hence us not agreeing on a way to do it yet) > > Is there anything else sensitive in the Client Hello?
Yes. (lower priority info, but nonzero) I'm of the philosophy that implementations should be open to arbitrary audit, but their messages should not give any info away that it doesn't have to. Frankly, figuring out how it can be misused is secondary; I assume it can. A hypothetical scenario: Lets say I've got a client using a device, and moving between multiple networks (e.g. joins various WiFi over time). Lets say the attacker is passive and cannot reliably know what the IP of our client is at all times. The user will most likely consistently use the same client software. Various different implementations will make various different choices with the many switches and options in TLS; fingerprinting implementations based on their ClientHellos is not that hard. If the user has changed anything from default that affects TLS via hellos, fingerprinting becomes much easier. This means that an attacker can one, guess what software the target user is using and make it easier to attack (and possibly decide to use active attacks at some point), and two, attempt to track a user with a changing IP across connections. Lets say our user goes through various WiFi networks and our attacker can listen in on all of them (not necessarily a tall ask), or we only care about a specific (set of) server(s) and can listen to their traffic. If the attacker can link the user to one IP, and see its ClientHello, then it can guess a window where the client switches from one IP to another, look for ClientHellos, and then narrow down the possibilities of who the target is in that list based on the prior fingerprint. If unique enough, or combined with other information to narrow it down further, the client can be identified across networks. There's of course other reasons clients can switch between IPs; Tor users can come out of different exit nodes over time. The point here is that not being able to fingerprint the ClientHello would make it much harder to track targets across IP changes. Additionally, whether or not a client is resuming a session is revealed in the ClientHello. This information can also be used to identify clients, and is itself potentially private information that the user may not wish to be disclosed. I'm sure we could come up with some other bits of information that get leaked that could be used in some creative way in the future. I also assume that some implementation will at some point put something incredibly stupid in its ClientHello that needs extra protection. I'd prefer we just attempt to always encrypt it all and call it a day. ;) > Either way, to properly > encrypt SNI with forward secrecy requires the same system that would be > necessary to encrypt the whole Client Hello. I get the impression that some people consider "proper" encryption of SNI to be something less important than getting it encrypted in any way. (e.g. a trial hashing idea was brought up) I'm not opposed to attempting to get a minimum viable SNI encryption scheme out there, but I think those efforts are better aimed higher. (and doing just SNI makes us less likely to consider full hello encryption in the future) > > The most practical short-term route would likely be to continue to hold our > > noses and expect cleartext SNI, but maybe provide a very simple way for > > servers to put a flag in a DNS record to opt-out entirely when they can do > > without. > > The point of encrypting SNI is so that you can hide a website on a shared > hosting host. If you have just one website on a host, there's nothing to > hide... Opting out by servers also makes the interesting targets more visible > (see also: email encryption). Point taken, but you can change your IP more often than your domain. Not using SNI at least increases the amount of effort required to figure out the destination. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
