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. > 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. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
