On 5/12/2017 7:58 PM, Dave Garrett wrote: > Encrypted SNI has been talked to death, and coming up with new schemes that > warrant air quotes in the subject around "encrypted" feels like a waste of > time. Wouldn't it be better to just focus on finishing the > encrypt-all-the-things approach and plan out a way to distribute a host DH > key (+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) > via DNS to encrypt everything straight from the ClientHello? Stick a > supported_groups in there as well and we can make HRR unneeded while we're at > it. This would also protect against 3rd parties attempting to fingerprint > clients via ClientHello parameters. (probably a few other things that could > be listed that could be helped, too) 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. > Simply put, some of us were convinced a while ago that encrypted SNI isn't > nearly as useful as it first seems, however fully encrypted hellos address > that problem and more. I think it'd be better to work towards a more complete > solution here than just worrying about SNI. 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.
-- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
