On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote: > On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote: > > 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) > > you then need mechanism to indicate which DNS key share client is using or > all > the connections would start failing on key rollover. And have to deal with > all > the "fun" stuff related to key rollovers.
It's possible to conceive of a way to do this with minimal trial decryption, or instead, we could just rotate the port with the key. (confusing firewalls is of course a problem, but that's something that could be dealt with) > > The private key > > would need to be protected and managed by the host (not the virtual > > servers) > > yes, the key MUST be assigned to a specific IP, not virtual host > > > > 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. > > 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) 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. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
