On 10/30/2016 01:04 AM, John R. Levine wrote:
To get back to the previous argument, if you don't want people using
DKIM to validate old messages, rotate the keys more often.
I'd suggest that as security services and political operatives have now
been alerted to the potential value of DKIM in validating leaks[1], any
realistic threat model now has to assume that the adversary/ies have
access to a complete DKIM public key history - at least for any sizeable
sender. Indeed:
* this may already have been happening for some time; and, depending
upon their means of information gathering[2]
* passive DNS operators may already have this capability as a
side-effect of what they've always done.
Those who are serious about plausible deniability can always use a
separate keypair per message and retire the public key after a long
enough interval for any likely delivery to take (60s? 2 minutes?),
thereby defeating all subsequent analysis, at least until/unless
ARC-signing by receivers becomes widespread. Whether this is a workable
approach, or whether the objective is even a good idea, appears to be a
long way out of scope for the DKIM specification.
Deliberately weak signatures strike me as a poor alternative.
Agreed. Worse still, trying to simultaneously pursue the "long enough to
support abuse prevention" and "short enough to support non-repudiation"
creates either of two unworkable situations:
* If we're "lucky", the former is shorter than the latter and we can
tweak the recommended key length to stay within the gap on a regular
basis until the end of time.
* If we're unlucky, the former is longer than the latter and we've
taken on an impossible objective.
In practice, neither length is likely to be able to be determined with
sufficient precision to support realistic decision-making.
- Roland
1: not to a forensic standard perhaps, but certainly to make real-world
determinations about whether a leaked document has been tampered with
2: collecting cached DNS data vs. crawling the DNS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html