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

On Aug 12, 2005, at 6:05 PM, Eric Allman wrote:
> 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.

These negative results when checking a revocation-identifier should  
occupy a minimum amount of cache resources, while also being retained  
for a brief period of time.  There would be a hit on the cache, but  
there would be a means to mitigate these lookups as well.  On the  
other hand, a key record may be introduced with a fairly long TTL  
with a far greater amount of resources consumed within the cache  
without a mitigation scheme.

> 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.

Intelligent people on this list have indicated a desire to deploy an  
inordinate number of keys.  You will see in the mass-rep draft, a  
suggestion to limit the possible number of selectors that could be  
used.  I am sure many see such a user-key commodity as attractive.  I  
too would want to have my own public key available to the world.    
The question that must be considered, would allowing user-keys in DNS  
potentially damage the DNS infrastructure, or perhaps, DKIM.  I think  
there is potential for harm.  A while ago I suggested that there be  
estimates made as to the relative impact this would have on both DNS  
cache and DNS traffic.  Perhaps a way to consider this would be to  
estimate the before an after average overhead per domain when DKIM  
becomes widely adopted (as I hope to be the case).

> Interesting proposal, but I wonder if it's realistic.  It seems to  
> presume that folks have implemented CSA in the first place.

Well, there are implementations (thanks to Tony), and the CSA record  
could actually do more than what is achieved with the SSP record  
which still at the starting gate.  The CSA record can authenticate  
the host domain via an address list, confirm that the domain  
administrator expects this host to be sending email, and provide a  
means to discover domain assertions that can be made in 15 available  
bits.  All this in one lookup that would be cached per host.  By  
recommending a convention that this record be used instead of the SSP  
records, and by also suggesting the HELO should be within the domain  
of the signature when possible (HELO may change within the session),  
then this would eliminate the need to do the revocation-identifier  
lookup for the majority of cases.  (Frankly, just the CSA record  
alone prevents many of the common threats to email.)

> 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.

Actually, CSA prevents this problem without needing to deal with  
signature verifications.  The CSA record, when used in conjunction  
with a lightweight reputation service, can also provide a significant  
level of DoS protect in the NAME SPACE alone that would be vital when  
defending a signature verification process.  This would also help  
reduce the onerous collateral damage that occurs when reputation is  
limited to the IP address.
The CSV draft suite should be updated soon, so perhaps we can better  
clarify how it works.  The entire CSV team would be in favor of  
supporting changes for the DKIM effort.  I told Dave about a year ago  
these two protocols were made for each other.
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim