Re: [ietf-dkim] ISSUE 1525 -- combine Arvel's, Doug's, and John's ideas

On Jan 18, 2008, at 11:53 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > There is a domain within the signature that should be used to  
> > assess compliance.  What prevents a valid signature of the From  
> > domain from allowing a message to comply with "all" or "strict"?
> The most interesting case for SSP is "no signature".
SSP should create compliance requirements for messages based upon From  
header's domain(s).   A "strict" or "all" compliance requirement  
should be met with a signature that could be valid for the From email- 
address's domain.  The signature should not need to be "on-behalf-of"  
the From email-address (as determined by the signatures i= parameter).
IMHO there should be an exception for restricted keys, where these  
signatures must be on-behalf-of the From email-address to fulfill a  
compliance requirement of "all" or "strict".
> For my unconvincing "toss a coin" list (Message-ID or first author  
> or Reply-To) it's of course possible to add "use any signature for a  
> domain in From addresses" to figure out a relevant domain for SSP.
It should not matter which header a domain's signature is on-behalf- 
of.  DKIM is not about establishing an author's identity.  The trust  
being established is with the signing domain.  The signing domain has  
the option of using ambiguous signature (no i= or no local-part and  
multiple email-addresses of their domain).  IMHO, the signing domain  
should be able to even use an opaque identity that does not associate  
with any header.  An opaque id could prove useful to protect someone's  
privacy.  A domain should be able to indicate they sign "all" without  
conveying anything more than that it was signed by their domain.
> But that only works if there is a corresponding DKIM signature, when  
> it's not really necessary to test SSP.
Just having a DKIM signature is not enough.  Domains protected by DKIM  
and an SSP assertion of "all" or "strict" must include a signature  
from a domain that would be valid for the From email-address domain in  
question.  The DKIM WG seems unnecessarily focused on the on-behalf-of  
feature of the DKIM signature.  This feature _might_ enable an MUA to  
highlight which identity the signature was on-behalf-of.  There may be  
cases where it is not possible for MUAs to establish which identity  
the signature was on-behalf-of.  In that case, just the signature  
domain could be highlighted.  Due to the possible on-behalf-of  
uncertainty, DKIM signature notifications must be able to convey just  
the domain of the signature.
Although compliance for "all" or "strict" could be defined to require  
an unambiguous on-behalf-of, such a requirement will make unambiguous  
on-behalf-of less certain.  The signing domain might then "falsify"  
the on-behalf-of to meet an unambiguous on-behalf-of.  Security  
concerns are better met by not placing constraints on the types of  
signatures used.  There are also the issue of body length, and subject  
lines where security might be impacted.  The verifier/MUA can use the  
information and display whatever they consider appropriate.  One could  
argue that excluding the subject line and including body length should  
not be used as well.  There is no reason to use SSP as a means to  
constrain these parameters.
> Or do I miss something obvious in your proposal ?  We could pick  
> John's proposal where Arvel's idea doesn't work, just look at all  
> domains in From addresses, for legit mail it's rare.  That needs  
> some "SSP processing limits" for malicious mails (not as badly as  
> for SPF).
EAI might wish to allow two From email-addresses to permit alternative  
formats.  SSP could assert that messages containing more than two From  
email-addresses are not complaint with "all" or "strict".  This would  
limit the number of policy search operations to two per message.   
Except in cases of restricted keys, SSP compliance should not depend  
upon which header the address is on-behalf-of.  Ensuring an  
unambiguous signature is within the control by the signing domain and  
is independent of SSP compliance.  MUAs are free to display  
ambiguously signed, body length, and excluded subject line messages in  
any manner they consider appropriate.  There is no reason for the DKIM  
WG to dictate how the on-behalf-of feature of the signature must be  
used before a domain can assert their signing practices or policies.   
Let the market decide.
-Doug



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