[ietf-dkim] Base issue: multiple linked signatures

[Douglas Otis]

On Jan 1, 2007, at 10:19 PM, Jim Fenton wrote:

> 1. There is nothing in the base spec that precludes multiple  
> signatures from being used in this way, except for the requirement  
> in Section 5.4 that the From header field MUST be signed.  So it  
> wouldn't be possible to detect a modification to the From header  
> field in this way.

It may prove a mistake mandating the signing of the From header once  
internationalization becomes common.  The From header mandate  
supports a highly dubious anti-spoofing effort based upon visual  
recognition.  A far more secure alternative applies annotations to  
digitally recognized originators.  Such an annotation scheme does not  
require troublesome From header stipulations and is not susceptible  
to various visual exploits, such as the use of look-alikes or cousin  
domains.


> 2. Providing a way to deal with header field modification was the  
> original intent of the z= tag/value.  At the time this was proposed  
> (prior to the formation of the WG), there was considerable concern  
> about verifiers using z= to "correct" a modification; since the  
> spec does not deal with presentation issues at all, there was no  
> way to indicate this to the recipient.  Telling the verifier to  
> replace header fields with the values from z= seemed heavy-handed,  
> so instead we got the strong "diagnostic use only" language not to  
> use the z= values for verification.  I would support some gentler  
> language that permits use of z= in verification, with particular  
> attention paid to ensuring that a new security vulnerability is not  
> introduced.

When the MTA is expected to verify DKIM signed messages, then the  
issue of signature selection become a fundamental problem not helped  
by the base DKIM draft.  Delving into how headers might be repaired  
only makes this situation worse.


> 3. All of this is a very incomplete solution to the message  
> modification problem, since it doesn't address body modification.   
> We already have a way to tell if a modified body is the cause of a  
> signature not verifying, because the bh= value won't have the  
> correct hash.  My solution would be for the modifier to sign the  
> message after modification.  The verifier might want to apply  
> reputation, accreditation, or other things like local whitelists  
> (all of which are out of scope here) to determine whether they  
> "like" that modification based on who did the modifying.

As signatures can be replayed, white-listing will likely prove  
impossible in many cases.  The assumption used in the base draft is  
that originating headers can be linked by a common domain.  This  
assumption may prove wrong, largely due to expenses in uniting email- 
address domains with that of the transmitting entities.  Transmitting  
entities may wish to sign outbound mail to protect their outbound IP  
address space.  DKIM signed messages are useful for directing abuse  
feedback.  Some large ISPs already experienced problems adding Sender  
headers containing their domain to their customers email messages  
containing different email-address domains.  Clearly, that is not the  
intended use of the Sender headers either.

A rather minor change to the base draft could significantly reduce  
the overhead related to signature selection when verification of a  
specific originating header is being checked.  This significant  
reduction remains possible by eliminating a restriction on the 'i='  
syntax to permit a linkage between a header and the signature even  
when domains differ. DNS records in the header domain can reference  
the signing domain as a means to validate the signature.  This  
approach eliminates a questionable practice of sharing private keys  
or delegating domains en-mass, as currently assumed by the DKIM base  
draft.  This approach provides email-address domain owners greater  
freedom of choice, and dramatically improves correlation of the  
transmitting entity when commonly represented by the signing domain.   
This last point can not be stressed more when there is any  
expectation that DKIM might be helpful at reducing abuse.

The use of CNAMEs to bridge domains represents the same overhead used  
to establish a relationship using a simple reference.  Reference  
association can be done autonomously, which means there is less cost  
related to deployment, while at the same time the transmitting entity  
is afforded greater protection.  Removing the restrictions on the  
'i=' syntax reduces the validation overhead and thus greatly reduces  
DoS risks.

-Doug