Re: [ietf-dkim] authentication result headers are an unsafe alternative

On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote:

> On 04/18/2006 14:18, Douglas Otis wrote:
> > Depending upon an unsigned "results" header being added to the  
> > message is an unsafe practice.
> > It is not practical to determine who added the "results" header,  
> > whether the MDA strips/adds all prior results headers, and whether  
> > all possible backup and alternative paths also strip/adds all  
> > "results" headers.  Retaining the integrity of the DKIM signature  
> > for a suitable period should permit message verification for  
> > transports that carry messages beyond the MDA.  Message protection  
> > beyond SMTP is an important aspect of DKIM.  Reliance upon a  
> > results header may produce many years of victims that DKIM  
> > intended to protect.
> > Explain the motivation for not including DKIM protection beyond SMTP?
> The problem is inherent in your statement, "a suitable period".   
> What's that and how do we figure it out?  If you include the MUA,  
> then the only suitable period is essentially forever.
The period of time a key should remain available would be for as long  
as messages are normally acted upon.  One or two months should cover  
the majority of cases.  The message may request dangerous actions,  
such as clicking upon a link.  When it is assumed normal for messages  
not to verify after a few days, individuals verifying DKIM signatures  
at the MUA would experience many valid messages with an unknown  
status.  This category of messages would create a potential for  
exploitation, which DKIM is attempting to avoid.

> If we decide to design for MSA/MTA/MDA, but do nothing that would  
> explicitly preclude MUA use (which is, as I understand it the  
> approach currently intended) then MUA based verifiers would likely  
> be able to work reasonably well, but without forcing us into a  
> corner on what "a suitable period" is for an MUA.
What is the difference between 1 week and 8 weeks?  How is one more  
of a corner case than the other?

> I would not say that we shouldn't include DKIM protection beyond  
> SMTP, but that whatever happens after delivery shouldn't distract  
> us from the primary use case.
Or the primary goal of offering protection for all obtainable use cases?


> Some method that can be relied on to store the verification result  
> for future use is going to need to be needed in any case so that  
> the verification state of stored e-mail can be retrieved when  
> needed.  Whatever solution that is, should also work for MDA to MUA  
> delivery of the result.
Logging of verification results would be independent of the DKIM  
related protection being sought.

> No reason that I can see that the MDA couldn't add an Auth results  
> header field, re-sign the message with it's own DKIM signature  
> (including signing the Auth results) and then deliver it.
Just as with the results header, even this MDA signing strategy  
depends upon the MDA/MSA properly handling such signatures.

> That would allow the MUA to rely on the results header field.   
> Since the MDA and the MUA are generally in the same adminstrative  
> domain, any key rollover issues could be handled internally.  I'm  
> not saying that's the right answer, just one possibility (and yet  
> another potential reason to solve multiple signatures).
I think this approach could be a good solution for several reasons.   
However, it would only be useful when the handling is defined from  
the outset.
-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html