Re: [ietf-dkim] What's a replay?

--On August 11, 2005 6:19:50 PM +0100 Tony Finch <dot(_at_)dotat(_dot_)at> 
wrote:

> On Tue, 9 Aug 2005, Eric Allman wrote:
> > 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?
> I'll just state my understanding of Doug's suggestion in a briefer
> form:
>
> The advantage of fine-grained revocation IDs over fine-grained keys
> is that a negative cache entry is much smaller than a key.
> Revocation IDs only have a DNS entry when they have been revoked,
> which should be rare. Key IDs will usually have a relatively large
> DNS entry.
Thanks, this does clarify.  What I'm worried about is that even in 
the case of small entries, the sheer number of queries required by 
RevIDs will still trash the DNS cache.  And I agree (and always have 
agreed) that using DNS for per-user DKIM keys would be a disaster for 
the same reason.
What Doug and I differ on (and neither of us has any data, nor is any 
data available today) is the extent to which senders will abuse g= to 
create per-user keys (really per-user selectors, each of which will 
have a separate key).  I agree that this would create a large load on 
DNS, and would trash DNS caches.  Doug seems to think that this would 
cause DNS to keel over and die, which I think is a huge assumption 
that he asserts without proof.  None the less, it is at least a 
possibility.
> Doug also suggests an optimisation based on when you could
> reasonably expect that checking for revocation would be
> unnecessary: if the message came directly from the signing domain
> (which you could detect using CSA, and which is the common case)
> you can skip the revocation check because it's unlikely that a
> message would be signed then revoked before it even travelled one
> hop.
Interesting proposal, but I wonder if it's realistic.  It seems to 
presume that folks have implemented CSA in the first place.  I find I 
can't really evaluate that proposal well, because I frankly find it 
hard to read.  (Example: step one reads "Obtain a domain name that is 
associated with the sending SMTP client."  But I couldn't find where 
it said what that association should be.  Without that I am very 
confused as to what CSA is supposed to be doing.)  But in any case, 
the general concept of "find the common case and use an optimization" 
is interesting.
But is the assumption that you can do this accurate?  Suppose someone 
at a large ISP gets a valid signature from that ISP, but then uses a 
zombie cluster at the same ISP to send that same message out.  At 
that point you would want to try to revoke the signature, even though 
it appeared to be coming from a "legitimate" source.
eric
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim