[Top] [All Lists]

Re: [ietf-dkim] DKIM Key Sizes

2016-10-30 05:14:31
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
<Prev in Thread] Current Thread [Next in Thread>