Re: [ietf-dkim] Seriously.

On Jan 24, 2008, at 11:54 AM, Jim Fenton wrote:

> Douglas Otis wrote:
> > 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).
Strongly disagree.  By applying the concept that a signing domain MUST  
confirm policy compliance prior signing, a signature on-behalf-of an  
identity within their domain permits an assumption of policy  
compliance for all other identities also encompassed by the signing  
key's g= and t= parameters.
> 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.
Agreed. But this overlooks Ned's consideration for a signature on- 
behalf-of the Sender where the signing domain encompasses the From  
domain, (and where the identity is not excluded by the signature's key  
g= and t= parameters).
> > 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.
Disagree.  When the From email-address is encompassed by the Sender's  
signing domain and is not excluded by the signature's key g= and t=  
parameters, there is no reason to assume the message does not comply  
with the signing domain's policies.  This concept covers all From  
email-addresses.  Policy referenced by the Sender's email-address  
domain matters little, and that is not what is being suggested.
> > 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.
When deciding compliance, these security gaps MUST be considered.   
When a message is signed on-behalf-of (i=) some other identity within  
the signing domain, and this identity does not appear within the From  
header, the key's g= and t= parameter matter.  In addition, when  
attempting to highlight which identities are signed, information not  
included within the signature's hash MUST BE excluded.  These  
represent significant security concerns.
In addition, a domain should be able to say they sign "all" and apply  
RFC 4871 as currently defined.  Presently, SSP requires significant  
changes to how RFC 4871 is applied.
-Doug



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