[ietf-dkim] chained signatures, was l= summary

[Douglas Otis]

On May 29, 2009, at 2:22 PM, John R. Levine wrote:
>> I don't understand what "cruft" you think I'm talking about.
>
> Telling people that it is reasonable to add a chain of A-R headers  
> to messages with broken signatures, and expecting recipients to  
> apply some ill defined algorithm to decide how much they believe  
> each level of alleged signature.

By having the l= value defined,  the length of the message that was  
signed has been make explicit, where appended notices or ads can be  
omitted which is the intended use of this parameter.  In the case of A- 
R permitted cruft, the l= value allows rechecking the body hash as a  
simple process when the DKIM header contains both the length and the  
signed body hash.  MUAs annotating signed messages already must  
exclude portions of the message not included in the hash from being  
annotated as having been validated by a signature from the signing  
domain.  The MUA may also check the reputation of the signing domain  
and wish to assert a green/red bar.   Even with the A-R header,  
without some means to trim off appended messages, which is the  
original purpose of the l= feature, recipient may confuse which  
message content and reputation should this apply, that of the signer  
or that of the provider.  They may easily be confused as to who they  
are trusting.  Those purchasing ad space may even attempt to leverage  
the resulting confusion.  Perhaps this issue should be reviewed in a  
few years.  Making changes now would be based upon conjecture.

> I would really like to remove l= from DKIM to make it clear that it  
> is not a good idea to even try to guess the history of a message  
> based on signatures that don't verify and cover the whole message.

Without the l= feature, annotations based upon DKIM may prove  
uncertain whenever providers are lax at applying notifications or  
advertisements.  It is purely guesswork as to how this situation might  
be best resolved.  It seems appropriate to make statements about any  
attempt at message annotations covering all portions of a message  
based solely upon A-R headers.   I don't think there is any burning  
need to add additional cautions about the use of the l= parameter.  It  
seems such effort is aimed at allowing sloppy and likely dangerous  
annotation practices.

-Doug