On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote: > The "server DH Key" poses a significant forward secrecy issue. Suppose > that the key is compromised. Now the secret police can find out what > nasty sites was accessed by whom. That can be plus plus not good for > said dissidents.
*This is the current situation.* "If the fix is broken, then it won't be fixed anymore" is not really that compelling of an argument, by itself. Of course the host DH key has an FS risk; it'd need to have a limited validity time and be rotated regularly. (probably weekly) The private key would need to be protected and managed by the host (not the virtual servers), and the public key would need to be given to the virtual servers to be listed in DNS for their domains. An attacker that can get that private key can revert the security to the current status quo, but the handshake would still set up an ephemeral DH key for FS of everything after the hellos (as is the current case, with the well known caveats with 0RTT data). An attacker that can reliably exfiltrate or completely control that key/host will almost certainly be able to surviel which virtual hosts are connected to no matter what we do. (or more precisely, I think that any gains you can make there are likely to be a lost cause) The only simple solution virtual servers have there is to not use a host you can't actually trust. Of course, if everyone just switched to IPv6, everyone can get their own unique IP, the offending virtual server nonsense becomes obsolete, and servers could opt-out of SNI entirely (e.g. via a flag in DNS). (yeah, those IPs are of course trackable, though more easily rotatable, but you're not going to get a perfect solution here without something like Tor) > EKR did propose a TLS in TLS tunnel back in December 2015: > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw. > It would effectively encrypt the "inner" Client Hello. Same basic concept, different implementation. TLS tunneling would provide some backwards compatibility; ClientHellos would still look like ClientHellos. I was just suggesting the simple generic route of encrypting everything in a non-backwards-compatible way (sent to a specified port that is set up to only handle that and reject everything else). I'd rather let stupid/incompatible stuff just break if we're designing a new opt-in system. The argument I'm making here isn't about implementation; it's about what to think about implementing to deal with the issues here. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
