Re: [ietf-dkim] DKIM Key Sizes

[Roland Turner <[e-mail]>]

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