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

[Douglas Otis]

On Feb 2, 2008, at 7:40 PM, Hector Santos wrote:

> 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).

FYI, DKIM=strict is now DKIM=discardable

So much for assertions based upon a perspective of what the signer  
does, and not attempting to dictate what an evaluator can do. : (

> 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.

Agreed.

But this 3PS type of message signature was the concern.

From: person at example.com
Sender: other-person at .example.com
DKIM-Signature:  d=expample.com i=other-person at example.com (g=*)

This message is clearly signed by example.com per RFC 4871, but where  
a SSP policy assertion of either "all" or "discardable" might cause  
this ABSOLUTELY valid message to be dropped as being non-compliant.   
(Hard to define compliance with the "discardable" assertion isn't it?   
Too bad this was not discussed on the WG list.)

>> 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

Agreed, however the issue was with respect to the local-part other-person at example.com 
  not meeting the requirements for "Author Signature" in SSP, however  
it does meet these requirements in ASP.

>> 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.

DKIM is silent upon what might be displayed.

> 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

You appear to be describing a comparison stated in ASP, and not the  
comparison in SSP.

> We need to keep our eye on the prize here and that is DOMAIN  
> protection,

Agreed.

> 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.

It would seem better to describe this as a means to evaluate  
compliance with Sender assertions pertaining to what the transmitting  
indicates as their handling practices.  This view makes less sense  
when the assertion is "discardable".

> 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.

The concern is when the message is signed by the author's domain, but  
on-behalf-of someone else with the author's domain.  When this domain  
applies their signature, their signing policy MUST evaluate whether "other-person at example.com 
" is able to include "person at example.com" with the From header.  It  
would be ridiculous to expect to have this policy applied by a  
possible verifier.  As you said, DKIM is about establishing  
responsibility _at_ the domain.  When the domain is held accountable,  
as designed in RFC 4871, the local-part introducing the message does  
not matter.  The local-part might be highlighted by the MUA to  
indicate who introduced the message, but as far as signing policy  
should be concerned, local-part is immaterial.

The local-part is only material when the key is g= restricted.  It  
seems reasonable for the the WG to make an exception for restricted  
keys.   Compliance could be defined as being met by a g= restricted  
key only when the associated identity is within the From header.  The  
use of g= restricted keys implies a signature added by an entity of  
limited trust where the domain may not be afforded an opportunity to  
establish compliance when the related identity is not within the From  
header.

-Doug