ietf-dkim
[Top] [All Lists]

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

2008-02-21 13:26:28

On Feb 20, 2008, at 9:55 PM, Jim Fenton wrote:

Jeff Macdonald wrote:
On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:

Expanding upon the effect of the SSP-02 Author Signature  
definition  based upon a conversation with Jim...

Jim suggested that to comply with SSP-02, signatures will not make  
use  of the i= parameter, since the i= parameter is needed only  
for g=  restricted keys.


Is that really true? I thought one could use i= in cases like so:

d=bar.org
i=(_at_)foo(_dot_)bar(_dot_)org

I didn't think g= was needed in that case.

Including the local-part is only required for g= restricted keys,  
where often the default of "i=@<d=domain>" is likely to be used.  A  
signature is not valid when the key is domain restricted, and the  
domain of the identity is within a sub-domain, which should make this  
case moot.

I was misunderstood here.  A local part on i= is REQUIRED if the  
signing key is "restricted" through use of a g= parameter other than  
*.  i= can be used at other times and for other things as well, as  
you point out.  In the example you gave, i=(_at_)foo(_dot_)bar(_dot_)org 
would result  
in an Author Signature when the Author Address on the message is  
something like jdoe(_at_)foo(_dot_)bar(_dot_)org(_dot_)

Although excluding the local-part from the i= parameter is possible,  
the identify of who introduced the message becomes ambiguous.  For  
example:

Sender: sdoe(_at_)foo(_dot_)bar(_dot_)org
From: jdoe(_at_)foo(_dot_)bar(_dot_)org
Dkim-signature: d=bar.org i=foo.bar.org (SSP-02 compliant with "all")

A perfectly valid signature identifying sdoe(_at_)foo(_dot_)bar(_dot_)org as  
introducing the message (per RFC 4871 definition where i= indicates on  
who's behalf the signature was added) would not be compliant with an  
SSP-02 assertion of "all"!

Sender: sdoe(_at_)foo(_dot_)bar(_dot_)org
From: jdoe(_at_)foo(_dot_)bar(_dot_)org
Dkim-signature: d=bar.org i=sdoe(_at_)foo(_dot_)bar(_dot_)org (SSP-02 
non-compliant  
with "all")

The SSP-02 Author-Signature definition _requires_ use of an  
"ambiguous" signature in these rather common cases.  So when the  
signing domain wishes to ensure clarity in who introduced the message,  
it must add an additional signature for the same message.  To defend  
against signature removal, the explicit signature needs to be included  
within the ambiguous signature, or, to ensure walking up the header  
stack does not lead to confusion when lacking the explicit signature,  
empty Sender, Resent-* headers must be listed to preclude their use.

The preclusion of headers when using a single signature will prevent  
practices that might have been able to preserve the original  
signature.  A potential for confusion results in the SSP-02  
requirement that the "Author Signature" MUST specifically identify the  
 From header address, or MUST BE ambiguous about the local-part.  This  
SSP-02 definition is attempting to ensure those using g= restricted  
keys are unable to sign compliant messages where the identity is not  
included within the From header.

SSP-02 would be a better specification and would create fewer problems  
by adding a non-normative statement that messages signed with local- 
part restricted keys where the identity is not within the From header  
should cause great caution, regardless of the SSP-02 policy  
assertions.  Would anyone disagree with such advice?

To allow the properly evaluation of results returned by a signature  
validation process, the following should be enumerated:

2 bits Signed By: no-one                        0
                  first-party                   1               
                  third-party                   2
                  authorized third-party        3 (future)

1 bit local-part restricted,                    0 not /1 is

1 bit domain restricted,                        0 not/ 1 is

2 bits policy: no policy                        0
               "all"                            1
               "repudiate-able"                 2
               "SMTP disavowed"                 3

1 bit TPA policy"                               0 not used, 1 used (future)     
                

Instead of a practice that offers an explicit token (even one that  
is  opaque) identifying the user/agent that introduced the  
message, once  again examining the header stack and guessing which  
header might apply  again becomes necessary.  It is also unknown  
whether the entire header  stack will have been captured within  
the signatures hash, so this  guessing may also be prone to the  
introduction of spoofed headers  while attempting to resolve top  
most identifiers.

Secondly, this also means that MUAs attempting to highlight who  
the  signature indicates as having introduced the message is also  
prone to  getting this wrong, because the signature's identity  
(i=) MUST BE  absent whenever the entity introducing the message  
is _not_ represented by the email-addresses within the From  
header. : (

Huh??  ASP does not prohibit other signatures, it just provides no  
additional information about them.

When the entity is not represented by the From header, to be specific  
about on-who's-behalf the signature had been added SSP-02 essentially  
requires two signatures be added.  Needing two signatures as part of a  
normal process adds overhead and complexity, and increases the  
difficulty of defending the verification process.  There is no  
justification for _requiring_ the use of multiple signatures.  No  
additional information is being added by the SSP-02 compliant  
signature.  This signature is purely wasted overhead that increases  
complexity and risk.

Although unlikely, some domains may feel compelled to sign the  
message  twice.  One signature to comply with the SSP-02 Author  
Signature  definition, and another to clarify who actually  
introduced the  message. : (


I think being able to use multiple signatures offers flexibility.

Sure, and doesn't signing the Sender header field clarify who  
actually introduced the message, if that's important?

RFC 4871 allows multiple signatures, but these multiple signatures of  
the same domain are needed _only_ because SSP-02 requires _less_  
information be contained within the policy compliant signature!

As a result, instead of DKIM offering a "reportable" or  
"displayable"  identifier clarifying who introduced the message,  
this identifier must  again be guessed. : (

I don't think it really matters who introduced the message. What  
really matters is if any of the DKIM identities are recognizable.

Yes, that's the point.

A DKIM signature from the Author Signature's Domain provides a  
recognizable identity, the _domain_.  Why stipulate the local-part  
MUST NOT be included within a signature in order to be SSP-02 Author  
Signature compliant when added on-behalf-of the entity represented by  
the Sender header?  The definition of Author Domain Signature should  
allow this type of signature to be compliant.

Jim's example as to why this definition is needed offers yet  
another  problem with this scheme.

Don't overlook the situation created by Jim's example, that when there  
is a desire to ensure the identity on who's behalf the signature is  
being added, ambiguous signatures only add to possible confusion when  
required these signatures are required to achieve compliance with an  
"all" assertion.  Wandering up the header stack when only one  
signature is used increases the likelihood of this identification  
process becoming prone to spoofing.

<snip>
Recommendation:

1) Change "Author Signature" to "Author Domain Signature".

2) Change "Author Signing Policy" to "Author Domain Signing Policy".

3) Accept the premise that when the "Author Domain" signs the  
message,  the message is complaint with the "Author Domain's  
Signing Policy" _by  definition_.

4) Only when the message is not signed by the "Author Domain", is  
the  "Author Domain Signing Policy" in need of checking.

These seem reasonable to me, but I don't know if we need to be that  
fine grained.

Just because the signing policy is expressed only at the domain  
level doesn't mean that the definition of Author Signature must also  
be at exactly the same level of granularity.  So an Author Domain  
Signing Policy can still deal with Author Signatures.

Compliance with your definition of Author Signature, when signing on  
behalf of an entity not within the From header, requires the  
signature's identity be falsified, or to remain ambiguous.  Forcing  
use of falsified or ambiguous signatures potentially enables  
exploitations, as the verifier/MUAs may attempt to guess the most  
likely identity.  These identities that may not have been included  
within the signature's hash as well, as this is not required.

Requiring two signatures be added in a specific order to retrain a  
secure indication of the i= parameter makes no sense.  This  
requirement only exposes the process to additional risks.  Verifiers  
will not have any trouble assessing the level of risk associated with  
a local-part restricted key where this identity is not found within  
the From header.  Policy is not needed to identify this type of  
signature as being risky.  The Author Signature is being overly  
restrictive as it precludes a signature from containing essential  
information.

-Doug

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