DoS and Replay protection for message signatures

Retraining a history of behavior based upon authenticated identifiers  
offers a means to protect systems from abuse that could otherwise  
lead to a denial of service.  However, message signatures offer _no_  
authenticated identifier prior to resources being committed.  While a  
signature's history could accrue against the domain name used to  
obtain the key, acting upon a bad signature's history by refusing  
service against the domain name comes too late to preserve  
resources.  This lack of resource protection becomes even more  
significant when confronting replay attacks.

One of the strengths of message signatures is having an ability to be  
independent of the IP address. A majority of domain owners share  
their address space, which makes a protection scheme based upon the  
domain name rather than the IP address desirable.  This goal can  
never be reached when IP address abuse history must be applied first  
in order to preserver resources.  The use of IP address history means  
either high levels of abuse must be tolerated, or a high level of  
collateral blocking may occur.

The HELO authentication process is essential for providing resource  
protect when domain names are used as a basis for history accrual.   
Suggestions have been made that a history of a key itself could be  
used.  While this may help identify new and possibly poisoned keys,  
this type of enhancement is better done with ancillary checks when  
new keys are discovered.  While retaining a key hash may be one  
method to track when a key changes, using non-recursive lookups could  
perhaps be another method.  The types of ancillary checks that could  
be used are many, but none of these schemes provide any resource  
protection.

Authenticating the HELO offers a solution to allow the feeding  
forward of a domain name's abuse history to a point in the process  
where resources can be protected.  Should it then be determined that  
the Signature's domain name is a parent of HELO, there should be no  
need to do further history or anti-replay checks.  This is where  
message signatures would benefit by a convention where there is a  
signing domain's relationship with the HELO in most cases.

For larger domains, the use of an opaque revocation-identifier is  
common.  DKIM should establish conventions for the placement of this  
optional information, where it is included within the signature.   
This convention could also establish a means to self-publish "bad- 
identifier" list.  This "bad-identifier" checking  also can work  
together with the HELO authentication to eliminate a need to perform  
the check.

There is another efficiency that could be obtained by authenticating  
the HELO prior to checking the signature.  Assertions of the types of  
mechanisms supported can be established concurrently with the HELO  
authentication.  It seems a holistic approach to message signatures  
should include a prior host authentication operation.

-Doug