Subject: [ietf-dkim] ISSUE: SSP-01 Unnecessary constraint on i= when asserting "strict"

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Dec 2007 10:36:29 -0800

A domain wishing to protect their transactional mail may decide to  
publish "strict" to limit the acceptance of "non-compliant" messages.

Compliance now requires the i= to not include a localpart, or for the  
localpart to match with the From header.

This unnecessary requirement may produce "false positive" detections  
of bad acts when signing domain uses i= as intended in the base draft,  
which is to indicate on who's behalf the message was signed.

Options to mitigate "false positives" would be to:

  1- Exclude the i= parameter
  2- Add another signature specifically signing the From as well

Option 1 eliminates _any_ significance the i= parameter could have and  
makes signature ambiguous.

Option 2 reduces significance of the i= parameters when the From  
header is signed "because it was there".

A requirement to have verifiers enforce which headers a domain should  
be signing seems over-reaching.  However, in the case of the g=  
restricted keys, there is already an expectation that verifiers will  
qualify valid localparts.

Solution:

When the "strict" policy is asserted, limit "restricted" keys to being  
compliant only when signing the From header.

This would not change restrictions already imposed on "restricted"  
keys, but would allow the i= parameter to be used as intended by the  
base draft, or in _any_ manner desired by the signer.

This minor modification would allow strict polices to:

  a- protect transactional messages

  b- allow the domain to run a mailing list, for example

  c- allow unambiguous signing of the domain's messages

  d- allow the identity expressed in the i= parameter to be opaque  
when desired

-Doug

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Dec 2007 11:18:24 -0800

Doug,

Thank you.

Now Issue 1519.

Eliot

Douglas Otis wrote:
>  d- allow the identity expressed in the i= parameter to be opaque when
> desired
>
> -Doug
>
> NOTE WELL: This list operates according
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 16:48:24 -0500

>   2- Add another signature specifically signing the From as well

Since the signer is controlled by the same entity, option 3 would be don't 
send messages where i= doesn't match what's in From.  

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Dec 2007 15:41:57 -0800

There seems to be quite a bit here I don't understand.

> localpart to match with the From header.

"Compliance" must be equivalent to "being not Suspicious".

> which is to indicate on who's behalf the message was signed.

I need an example to understand what would constitute a false positive.

> header is signed "because it was there".

All DKIM signatures MUST sign the From header field (RFC 4871, section 5.4).
> qualify valid localparts.

There is an expectation in the sense that the local-part of the signing
address MUST match the g= value.
> compliant only when signing the From header.

Again confused.  The From header field is always signed.

If you can describe the proposal in more precise terms, I'd be in a
better position to respond.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Dec 2007 20:23:45 -0800

On Dec 5, 2007, at 3:41 PM, Jim Fenton wrote:

>> Compliance now requires the i= to not include a localpart, or for  
>> the localpart to match with the From header.
>

Funny you should ask. : )

The word "suspicious" used in the SSP draft has different meanings.   
"Non-compliance" was meant to mean "not complying with the definition  
of a valid Originator Signature".  The "suspicious" term offers a  
negative connotation to define a state, and such connotation seems  
unnecessary for a specification.  The word "suspicious" is also found  
in three other places within the draft to imply different states.  The  
draft seems to presume these states are to be combined.  The  
specifications should not attempt this optimization without some  
experience indicating whether combining these states would be the  
right choice.

Having a valid "Originator Signature" was one way "suspicious" was  
defined, so technically no, I do not mean "suspicious" per the current  
definition of "Originating Signature".  I apologize for not adopting  
the "suspicious" convention.  Ironically, I was attempting to avoid  
confusion.

>> This unnecessary requirement may produce "false positive"  
>> detections of bad acts when signing domain uses i= as intended in  
>> the base draft, which is to indicate on who's behalf the message  
>> was signed.
>

Example 1:

A domain is signing all their email per DKIM base and are very careful  
about where all their email originates.  They go to great lengths to  
ensure the i= parameter indicates which header identity submitted the  
message (on who's behalf the message was signed).  Everything is  
running fine, and then the IT staff decides to publish an SSP policy  
of "strict" to curtail reports of spoofing because they were advised  
to do so in this situation.  Now they find messages from the office  
administrator of the CEO are being blocked at the MTA used by their  
accounting agency.  The signature accurately indicates the message was  
introduced by the office administrator.  After all, the office  
administrator is the only authenticated entity submitting the message,  
and the i= parameter accurately reflects this.  Clearly, the domain  
has done the "right thing" per DKIM base.

Per the definition of Originator Signature, only a signature "on  
behalf of" the From header can qualify as being valid.  Or more  
technically, a message submitted by the office administrator for the  
CEO will not be compliant with this definition of Originator  
Signature.  In essence, a verifier is expected to know better than the  
signing domain which headers are to be referenced by the i=  
parameter.  With this restriction placed upon the i= parameter,  a  
policy of "strict" will then make such messages as non-compliant with  
the definition of Originator Signature.  A valid Originator Signature  
is required to be compliant with "strict".  The IT staff might ask  
themselves whether they should have waited for SSP to have been  
finished before deploying DKIM.

Example 2:

A domain is running web based commerce and mailing-list on the same  
domain.  They feel using the same domain improves their branding,  
makes it easier for their customers to remember, and better protects  
their users from phishing.  This mailing list signs the RFC2921 List- 
id headers and does not use (or overwrite) Sender headers.  While  
allowing anyone to subscribe, this domain ensures only specific role  
accounts within their domain are able to post to the mailing list.  As  
with example 1, the domain is very careful about where all their email  
originates, and they also wish to protect their transactional  
messages.  After publishing a "strict" policy, they then receive  
complaints many subscribers are no longer able to receive list  
messages from their role accounts.

Example 3:

A large well-known domain issues transactional messages, where some  
messages serve as an introduction service.  These messages facilitate  
an introduction by placing a first-party email-address within the From  
header.  At times, the introduction address is that of "complimentary"  
or account on the domain when some customers want to remain  
anonymous.  Each message is signed with an opaque-id which internally  
defines the transaction, and has nothing to do with the identity found  
within any header.  This domain also wishes to protect their  
transactions, but find when they publish "strict", their  
"complimentary" email is blocked, even at their own MTA.

>> Option 1 eliminates _any_ significance the i= parameter could have  
>> and makes signature ambiguous.
>>

Sorry, "signed" should have been "Originator Signed."  Of course the  
 From header is always part of the hash being signed.  The definition  
Originator Signature requires that if the i= parameter includes the  
localpart, it MUST indicate that the signature is "on behalf of" the  
 From header or remain ambiguous.

>> A requirement to have verifiers enforce which headers a domain  
>> should be signing seems over-reaching.  However, in the case of the  
>> g= restricted keys, there is already an expectation that verifiers  
>> will qualify valid localparts.
>
> There is an expectation in the sense that the local-part of the  
> signing address MUST match the g= value.

Of course, but this restriction is normally "ANY".

>> Solution:
>>
>> When the "strict" policy is asserted, limit "restricted" keys to  
>> being compliant only when signing the From header.
>

Sorry again.  "Originator Signed" per the current definition.  This  
definition requires the verifier enforce a restriction on which header  
the domain can indicate who they are signing "on behalf of".  "On- 
behalf-of" can only be determined by the i= parameter.  When the  
domain is signing their own messages using unrestricted keys, they  
should be able to control what is allowed. The Originator Signature  
expects verifiers will impose their policy restriction on which  
headers the domain is allowed to sign.  With the exception of  
"restricted" keys, there is no reason for verifiers to be imposing an  
i= or "on-behalf-of" restriction.

> better position to respond.

Suggested edits to the definition of Originator Signature (and a  
corrected mistake) have been sent to the list.  The edits also added  
the word "domain" to the introduction regarding what is generally  
checked by the verifier when qualifying messages.  This change will  
reduce the overhead associated with these corner cases that are likely  
to cause a "false positive" detection of possible spoofing.  As few  
domains will be checking SSP, it behoves all domains to do their own  
policing as to which headers they signed.  It makes sense to depend  
upon this assumption.  This change allows DKIM to be used in  
interesting ways without causing email to break.

-Doug