ietf-dkim
[Top] [All Lists]

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

2007-12-05 21:25:48

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

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

Douglas Otis wrote:
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.

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

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.

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

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.

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

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

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.

Again confused.  The From header field is always signed.

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.

If you can describe the proposal in more precise terms, I'd be in a 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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html