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