ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposed issues addressed by SSP-03 for closure

2008-03-03 15:17:31

On Mar 1, 2008, at 6:55 AM, Jim Fenton wrote:

I'd like to shorten the list of open issues, so I'll start with the  
issues that I consider clearly moot in the ASP draft (-ssp-03) or  
that are duplicates of other issues.  Hopefully these are non- 
controversial.

WG chairs, I'd like to ask that you direct the closure of the  
following issues, subject to WG consensus, of course:


1399    clarify i= vs. SSP

Duplicate of 1519.

Disagree.

Issue 1399 suggests i= might be included within an "all" signed  
policy, however lacks details.

Issue 1519 notes SSP policy requirements conflicts with RFC 4871 and  
recommends against restrictions on the i= parameter for unrestricted  
keys.

Per the DKIM charter of out-of-scope topics:

* Signatures that attempt to make strong assertions about the identity
   of the message author, and details of user-level signing of messages
   (as distinguished from domain-level keys that are restricted to
   specific users).

* Duplication of prior work in signed email, including S/MIME and
   OpenPGP.

Despite being out-of-scope, the SSP Author Signature definition  
dramatically changes i= parameter use in "compliant" signatures.  The  
change in i= parameter's use was made by stipulating "compliant"  
signatures containing the local-part of an identity must be on behalf  
of the entity within the From header.  RFC4871 never stipulated a  
valid signature's associated identity contain an email-address found  
within the message's headers, nor that this identity be specifically  
within the From header.

Compatibility with RFC 4871 is only achieved using identity ambiguous  
signatures in many cases, leaving verifiers to guess (wrongly in some  
cases) by looking up the header stack.  To retain specificity of non- 
 From header identities, an separate signature is required and it must  
properly overlap that of an ambiguous signature.  There is _no_ reason  
to assume providers will make assertions regarding the specific  
identity of the message's author.  Providers may wish, or be  
compelled, to use opaque tokens instead.  Whether such identity  
assertions are made is out of scope for DKIM.  Not surprisingly,  
limitations on identity assertions limited to specific email-addresses  
within the From header for SSP "compliance" is not compatible with RFC  
4871 either, in addition to being out of scope.

Use of the i= parameter containing a token representing the user or  
agent on whose behalf the signature was made offers a significant  
level of protection for receivers.  This protection can help curb  
abuse from compromised systems, especially when users are permitted to  
send messages irrespective of identities within From headers.  Abuse  
is normally controlled by identifying abusers, and not by constraining  
all the domain's users messages.  The level of constraint used should  
remain within the purview of the signing domains.  The protection  
afforded by a valid (even tokenized) on-behalf-of identity is lost as  
a result of the change imposed by the Author Signature definition.  A  
definition that demands _less_ information be conveyed in the signature.

A domain may wish to assert all of their messages are signed to raise  
the scrutiny given unsigned messages from their domain.  Nevertheless,  
the identity of the Author remains an independent and totally separate  
issue.  Ironically, this definition inhibits use of identities of  
those introducing the message and on whose behalf the signature was  
added when not also found within the From header.  Any issues related  
to the spoofing of the Author still remains within the signing  
domain's purview and can be prevented by not signing spoofed or  
abusive messages.

The only justification to limit "compliant" signatures to those  
identities found within the From header would be for messages signed  
with g= restricted keys.  Such messages should be flagged "non- 
compliant" regardless of what policy the domain publishes.  Such  
messages can easily represent abuse beyond the signing domain's  
purview.  Not flagging these messages as being "non-complaint" would  
impose a significant security risk fully independent of any SSP policy  
assertions or author identities.   SSP should only stipulate that  
signatures containing identities not found within the From header  
signed with g= restricted keys are to be considered "non-compliant"  
with _any_ domain signing policy.  In addition, such stipulations  
SHOULD NOT depend upon whether a policy has been published.

-Doug

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