[ietf-dkim] What's a replay?

[Eric Allman]

Doug, I'm clearly not understanding something.  I hope I'm not 
misrepresenting you here; if so it is out of misunderstanding, not 
maliciousness.

You have said that you are opposed to per-user keys because of the 
potential damage to DNS (or at least that's my understanding).  I 
think this is a legitimate concern even if it doesn't actually damage 
DNS, since the large number of queries for different values will 
trash caches on DNS servers.

But you are also pushing revocation ids.  For those to be useful they 
have to be fine granularity (if they have the resolution of a 
selector then they don't have much point), perhaps even finer than 
per-user keys (since they could be per-message).  They also need to 
have short TTLs, for obvious reasons.

It seems like the obvious place to store revocation information is in 
DNS (so that you don't start having to add additional ports, which is 
a problem from a firewall perspective).  If you don't store the 
revocation ids in DNS then you have substantially raised the bar for 
using DKIM.  But if you do store them in DNS, aren't you actually 
trashing DNS in exactly the same way as with per-user keys?

eric