[ietf-dkim] Base-04 // Semantics of Multiple Signatures

[Douglas Otis]

Looking for a solution with regard to this statement:

,---
|4.  Semantics of Multiple Signatures
|...
| Signers SHOULD NOT remove any DKIM-Signature header fields from
| messages they are signing, even if they know that the signatures
| cannot be verified.
'___

There should be additional advice provided allowing the signing  
domain a means to avoid verification failures and the verifying  
domain a means to avoid unnecessary verification attempts.

A process that verifies DKIM signatures should limit the number of  
attempts.  This comment however ignores the affect of a verification  
limit or that there is a DDoS potential when reasonable limits are  
not placed upon the verification process.  One technique for  
excluding invalid signatures would be to inspect the DKIM signature  
header field bh= tag.  The l= parameter could be compiled for all  
signature verification candidates, and compared against the bh= tag  
value during the hashing process when the l= tag is satisfied.   
Checking the bh= tag in this manner offers a means exclude many  
invalid signatures.  The hashing process should be faster than  
signature verification until the message exceeds some size, such as  
100 KB for example.  A trade-off based upon message size might also  
rate limit the verification process.

Unfortunately, there is not a separate hash value (or even a simple  
checksum) for headers.  It is possible that a signing domain might  
introduce a header, without altering the message body.  If this added  
header causes a set of signatures to become invalid that also contain  
a valid body hash, this may result in the added signature not being  
verified.  Verification limits could be very low, especially  
considering as much as 80% of email may be undesired.

There are possible strategies to avoid this situation.  One technique  
could intentionally obfuscate the bh= hash values to ensure known  
invalid signatures do not consume verification attempts.  The  
obfuscation technique could overwrite the first base64 encoded bh=  
value with the '!' character.  This obfuscation technique allows  
diagnostics a means to recover this value when attempting to  
determine the cause of a signature failure.  One other somewhat  
intrusive strategy could prefix information to the message body to  
ensure the bh= hash excludes the consideration of the signature.  The  
bh= value obfuscation technique seems significantly less intrusive.

-Doug