ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP-02 the problem with Author Signature

2008-02-25 18:51:58

On Feb 25, 2008, at 3:35 PM, Jim Fenton wrote:

Doug,

Much as I appreciate your personal appeal, it's really the rough  
consensus of the working group, and not my opinion, that matters.

Jim,

Thank you for your feedback.

Of course consensus matters, but so does compatibility with RFC 4871.   
The SSP-03 draft will cause valid DKIM signatures applied by the From  
domain to be non-compliant with SSP "all" assertions.  This happens  
when the i= parameter is used to indicate the on-behalf-of user/agent,  
but this identity does not represent the From email-address.  Domains  
attempting to clarify which identities have been authenticated by  
setting the i= parameter are prevented from doing so without applying  
multiple signatures, or leaving user/agent identities ambiguous.  Use  
of multiple or ambiguous signatures creates new risks.

If I understand correctly, the difference between the approach you  
favor and the one that I favor is as follows:

Approach A (favored by Doug): Check the g= tag on the key referenced  
by a valid signature, if present, compare it to the local-part of a  
From address to determine if the signature is an Author Signature.

No, the g= tag is to be used by untrustworthy systems.  When the key  
g= tag restricts the identity, and the i= identity is not found within  
the From header, even a valid signature MUST BE considered to have  
UNKNOWN DOMAIN SIGNING COMPLIANCE.  It does not matter whether the  
domain makes policy assertions with respect to this specific and  
unusual case.  This type of signature MUST BE excluded from being  
considered compliant with any domain policy, and SHOULD NOT cause  
trust for the domain to be applied.

After excluding restricted key signatures containing a non-From header  
identity from being considered DOMAIN COMPLIANT, then only the domain  
of the signature, and the domain of the From header email-address  
require evaluation.  This approach permits the i= parameter to  
_always_ represent the user/agent without the identity even being  
contained within the message itself.  The A Approach is thus far more  
compatible with RFC 4871.

Approach B (favored by Jim):  Compare the i= value on a valid  
signature (or its default value) against a From address; if the i=  
value has a local-part, then it must match the local-part of that  
From address.

This is directly in conflict with RFC 4871's definition for the i=  
parameter.

If there is a g= tag in the key, then there must be a matching local- 
part in the i= of the signature in order for the signature to be  
valid, so the approaches are approximately equivalent in this case.

If there is not a g= tag (or if its value is *), and if there is no  
local-part in the i= of the signature, then the approaches are also  
equivalent.

The difference appears when there is not a g= tag (or if its value  
is *) and the i= contains a local-part.  Approach A would consider  
this to be an Author Signature regardless of the local-part, and  
approach B would only consider this to be an Author Signature if the  
local-parts match.

This overlooks the exclusion that any evaluation process should make.   
In the Approach B, the UNKNOWN DOMAIN SIGNING COMPLIANCE when the key  
g= tag restricts the identity, and the i= identity is not found within  
the From header is never notices unless policy is being evaluated.   
This makes Approach B less safe, and less compatible with RFC 4871.

My rationale for B is that it allows a domain to apply a signature  
not representing an author sharing the domain.

Approach B may require an ambiguous signature or two overlapping  
signatures.  In the case of just a single ambiguous signature, the  
identity of the user/agent on whose behalf the signature was added  
must be guessed by looking for headers that might exist above the From  
header.  Requiring two signatures may tend to prevent in session  
evaluations from being practical.  In essence, Approach B requires  
possible removal of information permitted by RFC 4871 from the  
signature, where restoration of this information may necessitate a  
second signature.

While we haven't gone through the details of how mailing list  
signing might work, there might be times when such an agent might  
want to sign a message, but explicitly not as the author.  It also  
does not require the retention (or re-retrieval) of the key  
information in evaluating whether something is an Author Signature.

Approach A requires restricted keys for non-From identities to be  
noted, but this notation SHOULD BE done regardless of any policy  
assertion.  For Approach A, beyond that specific notation step, only  
the domains of the signature and the From email address then play a  
role in signature compliance.

As I understand it, your rationale for A is that it allows the local- 
part of i= to be used for an opaque tag representing but not  
revealing the identity of the user or agent for which the signature  
is being applied.

Exactly.  This parameter is the _ONLY_ identity currently defined upon  
which a verifier may employ to defend against abuse related to  
compromised systems or malicious users having the freedom to use any  
 From header address they wish.  A user's freedom to use any From  
email-address is independent of the signing domain's policy assertions.

My response to this is that there are lots of other places an opaque  
tag could be put, since it is local to the use of a particular  
domain, and can be done without interfering with the ability of a  
domain to sign as other than an author.

Only Approach B interferes with an ability to identity the agent/ 
user.  No other tags have been defined for this purpose.  Defining yet  
another tag for the same purpose is not needed when compatibility with  
RFC 4871 is retained.

-Doug





-Jim

Douglas Otis wrote:
Jim

As the cut-off approaches, this is an appeal for you to reconsider  
where agreement might be found.

Risks associated with the use of g= restricted keys signing  
messages where i= identities are not found within the From header  
exists whether policy is asserted or not.  A g= restricted key  
signifies the signing is restricted due to limited trust.  In other  
words, the message signed by such keys may not be controlled by the  
domain's signing practices, whether any policy records are  
published or not.

Being aware of the risk associated with local-part restricted keys  
REQUIRES the presence of this restriction be indicated the DKIM  
validation process, or this risk can not be accurately assessed.   
The risk related to the use of g= restricted keys does not change  
substantially when the domain also asserts they sign "all"  
messages.  Domains asserting such policy are also likely more  
cautious about the distribution of these local-party restricted  
keys.   Why limit weighing this risk with local-part restricted  
keys to just rare situations where domains assert a DKIM policy?   
Otherwise, use of restricted local-parts not within the From header  
is likely indicative of messages attempting to phish or spam using  
keys purloined from someone's laptop.

You seem fairly determined to keep your version of the "Author  
Signature" definition you feel designed to address this concern,  
but only in fairly limited situations.  This definition, in many  
cases, prohibits use of user/agent specific information regarding a  
token directly associated with signatures without also implementing  
multiple signatures, or expecting verifiers to guess identities by  
picking the higher header within the message header stack.  This is  
most unfortunate, as the value DKIM may have had in curbing abuse  
depends, to a substantial degree, upon the definition expressed  
within RFC 4871 for the i= parameter.  This definition permits the  
i= parameter to serve as a token for the entity introducing the  
message (on whose behalf the signature was added).  This token  
enables simpler feedback reports, and defensive measures that can  
be used by receiving domains.  "They can use multiple signatures  
when they wish to be specific" sounds too much like "let them eat  
cake."  This statement represents an excuse for an awkward and  
erroneous definition that overlooks the intent of RFC 4871, and the  
increased overhead, complexity, and risk.

A defence afforded by meaningful tokens of the user/agent is not  
affected by a value being opaque and matches nothing within the  
message.  Such an opaque value would be compliant with RFC 4871.   
The i= identity's real value is found as a token that can track  
sources within a domain of compromised systems.  Whether the token  
represents an obscured machine or person does not matter.  Even an  
i= identity changing every day still provides useful information  
when dealing with large domains where blocking at the domain is  
truly onerous.

In addition, the Author Signature restatement of the definition for  
the i= parameter is plain wrong.  One can not say the i= parameter  
represents on whose behalf the signature was added, and then say  
this identity must also represent the email-addresses found within  
the From header.  Such a definition must be wrong in many cases.   
DKIM is not about ensuring that the identity of an individual  
matches that of an email-address contained with the message.  Such  
matching is completely optional, since DKIM is _not_ attempting to  
replace S/MIME or OpenPGP.  As such, there is no reason for DKIM  
policies to then stipulate what identities are permitted to  
represent the on-behalf-of entity.  The recognizable identity  
offered by DKIM is the _DOMAIN_.

Your Author Signature definition forces recipients into guessing  
which header might contain the identity on whose behalf the  
signature was added.  This may happen when, to be compliant with  
the Author Signature definition, the signature remains ambiguous as  
a path of least resistance.  Guessing identities then opens the  
door for spoofing, especially when multiple signatures are added,  
but perhaps in the wrong order.  It is ironic most DKIM messages  
are not processed during the SMTP transaction, where a policy  
definition expecting use of multiple signatures only makes this  
goal less obtainable.  This definition causes the signature  
processing overhead to be more complex, and more error prone, and  
less safe.  Anyone using DKIM naively thinking that, because they  
sign all their messages using RFC 4871, they can then make a DKIM  
policy assertion they sign "all" their messages, will be in for a  
rude awakening due to your definition of Author Signature.

-Doug





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