Re: [ietf-dkim] Seriously.

Douglas Otis wrote:
> On Jan 23, 2008, at 10:11 PM, Jim Fenton wrote:
>
> > Ned Freed wrote:
> > > > I would really love it if we could get past the meta-discussion of 
> > > > "is the multiple From: case important?" to the proposals that have 
> > > > been made to address the issue.  These include:
> > > > 1. Perform SSP checks on the domains of all From addresses in the 
> > > > message, with the exception of addresses having valid Author 
> > > > Signatures.  If any of the checks result in a Non-Compliant 
> > > > (formerly Suspicious) result, then the message is considered 
> > > > Non-Compliant.
> > > > or
> > > >
> > > > 2. In the case of multiple From: addresses in the message, and the 
> > > > domain part of one of the addresses matches the domain part of the 
> > > > Sender address, then perform an SSP check on that address unless it 
> > > > has a valid Author Signature.  If the Sender header field does not 
> > > > match the domain of one of the from address or is missing 
> > > > [violating 2822], revert to alternative #1.
> > > This is an interesting, even novel approach. I'm still trying to 
> > > evaluate it. One question I have is how it would interact with what 
> > > headers are covered by the author signature. In particular, does the 
> > > Sender: field in this case have to be covered by the signature?
> > It might need to be, but I have a bigger concern about alternative 
> > 2.  The Sender address and From address(es) have different meanings.  
> > Just because a particular author happens to be the sender of the 
> > message, should that affect which domains' signing policies apply?  I 
> > can't see why it should, which is why I favor alternative 1 given 
> > that we're not going to do something arbitrary in the multiple-From 
> > case.
> Jim,
>
> The Author's email-address is not contained within the Sender header.  
> When a message is not complaint with policy, the signing domain MUST 
> NOT apply their signature.  SSP confirms the policy of the signing 
> domain when policy is not already apparent via their signature.  SSP 
> is not about the policy or identity of the author as you seem to suggest.
First two sentences:  Agree
Second two sentences:  Disagree strongly.  Policy associated with a 
valid signature more properly belongs in the key-record (selector) 
referenced in the signature (example:  acceptable hash algorithms).  SSP 
has to do with messages lacking, potentially, any valid signature at 
all, and the author domain(s) is/are used as the key to retrieve SSP 
from it/them.
> Ned accurately said when a signing domain is also authoritative for 
> From address domain in question, then this email-address can be 
> considered signed as well.  The signature's hash for some identity 
> within the signature's domain MUST include all From email-addresses.  
> When the signature's domain is authoritative for the From's 
> email-address's domain, (unless by a g= restricted key) the message 
> MUST BE assumed to meet the signing domain's policies.
My concern has to do with whether the SSP of the other From (author) 
domains has to be considered as well.  Just as the point has been made 
that it's not proper to handle this case by arbitrarily picking the 
first From domain, I believe that it's also not proper to use Sender for 
this purpose.  Given that belief, the question of whether Sender is 
signed or not is moot.
> RFC 4871 has some dangerous gaps within the specification.  A g= 
> restricted key can be used to sign on-behalf-of any header.  The 
> identity contained within the signature might match that of some 
> header, however this header is not required to have been included 
> within the signature's hash.
There was language in earlier versions of the dkim-base draft, "any 
header field that describes the role of the signer...MUST also be 
included" but that text was removed by WG consensus.  I don't consider 
this to be a dangerous gap, however.  RFC 4871 describes the process for 
constructing and verifying DKIM signatures; the context for what valid 
signatures are useful for what purposes lies outside that scope.
-Jim

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