On Jul 11, 2017, at 3:59 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > I can't see that happening. Once the first example.com <http://example.com/> > is called > out for using this, others will make their list longer or take > other approaches, e.g. use one exfiltrated private value as a > seed for others via some proprietary mechanism.
Ah, you mean the first time the attack happens in the wild. Sure, I can see that, but that gains the attacker no real advantage over just exfiltrating all the keys. Once you make the number of keys large enough to be hard to detect, you have a really big key management problem. Might as well just make it a logging problem. So we've forced them to do the thing that makes pervasive monitoring hard and point monitoring easy. I call that a win. Note that if we took a distributed approach to discovering key reuse, it would be almost impossible for any large site to conceal. > Actually, that calls out another reason to not standardise or > further develop this - any such standard is either undetectable > or leads to deployments deviating from the standard to become less > detectable - both undesirable outcomes. That latter case also > destroys the "but we should scrutinise it" argument IMO as the > "it" will change to be undetectable and not the "it" that was > ostensibly scrutinised. I'm not arguing in favor of standardizing this. I think it's an attack, and there is a countermeasure which is worth documenting, and possibly worth deploying. If the working group does a CFA on the draft, I will argue against adoption. I like Christian's approach—document this in an appendix, _as an attack_.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
