On Jul 11, 2017, at 4:58 PM, Ted Lemon <mel...@fugue.com> wrote: > On Jul 11, 2017, at 4:31 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie > <mailto:stephen.farr...@cs.tcd.ie>> wrote: >> I'd bet folks would invent proprietary >> ways of avoiding detection, that deviate from the "standard" >> and that perhaps make crypto worse all around. Say by deriving >> secrets from some function f(exfiltrated-secret, time, count) >> for a small counter or some such and having the decryptor of >> the wiretapped packets hunt a bit for the right key. > > Hm, well, but that would be catnip for security researchers, particularly if > it weakened the key. But yeah, you're right, that does make detecting the > attack possibly impractical aside from as a large research project.
On second thought, this suffers from the same problem as the many-static-keys problem: there are too many moving parts. This requires all clocks on all servers and interceptors to be in perfect sync, not just close, or else potentially halves the performance during clock skew overlap periods. It requires every server and interceptor to implement the same algorithm. And you still have to distribute the information from which the key is derived. So again, yes, you can do this particular mitigation strategy. But it's expensive, and so nobody's going to do it if they have a better choice. It's cheaper to just re-tool to support TLS 1.3. As long as the solution isn't standard, it's only going to appeal to a _very_ limited audience, if there's any audience for it at all. E.g., consider trying to deploy something like this on a country-wide scale. You're just going to exfiltrate every key instead—it's cheaper.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
