[ietf-dkim] draft-ietf-dkim-ssp-02.txt

[Hector Santos]

Douglas Otis wrote:

> RFC 4871 clearly indicates the i= parameter is _intended_ to identify 
> the user or agent for which the message is being signed.  When a 
> signature is added on-behalf-of an entity whose email-address is found 
> within the Sender header, and where the message happens to include a 
>  From address within the same domain, the definition for Author 
> Signature within the SSP makes the signature specified by RFC 4871 
> non-compliant with an "all" or "discardable" policy assertions, however 
> the definition within ASP does not.  

Sorry, I don't see it.  I am going to ignore ASP/SSP-02 and deal with 
SSP-01 because it is well understood and not subject to the majors 
security issues in ASP/SSP-02.

DKIM=ALL means ANYONE can sign, but it must be signed.
DKIM=STRICT it must be signed by the AUTHOR (ORIGINATING DOMAIN).

This would be a 1PS:

    From: person at domain1.com
    Sender: listadmin at listdomain.com
    DKIM-Signature:  d=domain1.com i=person at domain1.com
                     h= may include Sender: binding

For a 1PS scenario, domain1.com SSP policy can be:

    DKIM=unknown    (weak protection)
    DKIM=ALL        (protection against non-signed mail)
    DKIM=STRICT     (protection against non-signed mail and 3PS)

This would be a 3PS:

    From: person at domain1.com
    Sender: listadmin at listdomain.com
    DKIM-Signature:  d=listdomain.com i=listadmin at listdomain.com
                     h= SHOULD (good idea) include Sender: binding
                        since it was the signer.

For a 3PS scenario, domain1.com SSP policy can be:

    DKIM=unknown    (weak protection)
    DKIM=ALL        (protection against non-signed mail)


Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i= 
must be the same or be a sub-domain of d=.

Per x822, Sender: is OPTIONAL and not a network required control header. 
  It is more information than anything else.  Furthermore, not everyone 
supports Sender: unlike From: which is a requirement.

I see no conflict.

 > SSP stipulations changes RFC 4871
> signature handling to not use the i= parameter when there might be such 
> a conflict with the From header.  

Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i= 
must be the same

Per x822, Sender: is OPTIONAL and not a network required control header.

> Not surprisingly, RFC 4871 never 
> suggested the i= parameter not be used when there might be a conflict 
> with an address within the From header.  

What conflict?

It is clear in 4871 section 6.3:

    If the message is
    signed on behalf of any address other than that in the From: header
    field, the mail system SHOULD take pains to ensure that the actual
    signing identity is clear to the reader.

The logical association implies for this to be:

       ([i] == d) != From

which is the fundamental basis for a 3rd party Signing operation.  Like 
wise, the logical association for a 1st party signature is:

       ([i] == d) == From

We need to keep our eye on the prize here and that is DOMAIN protection, 
to assist it in keeping with its new asserted DKIM-BASE "social and 
ethical" responsibility.   SSP is basically a fraud detection or 
protocol consistency checker.  If everything is koshser, I believe no 
one has ever said SSP allows a message to pass or skip any other testing.

Traditionally, by far, the From: is the author of the message. It is 
reflective in all mail systems.  The author does not mean it has to be 
the signer, and I hope no one is claiming a 3rd party signer is an 
AUTHOR and/or copyright holder of the message content.


-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com