-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Wednesday, January 23, 2008 10:12 AM
To: Siegel, Ellen
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Seriously.
Siegel, Ellen wrote:
If you have an authentic claim of responsibility from a trustworthy
party (as per #1), why should it matter whether that party is
represented
by the From: header or the Sender: header? And why, if the
authenticated
party in the Sender: field is trustworthy, should it be required that
the
From: domain is authenticated directly?
This all seems counter to the idea that reputation is the real
differentiator. You seem to be saying that a trustworthy,
authenticated
signature related to the Sender field is worthless, but any
authenticated
signature related to the From: field is goodness. Taking that to its
logical conclusion, spam signed with a signature based on the bogus
From:
domain will be rated better than valid mail signed with a well-know,
trusted 3rd party signature based on the Sender field.
The SSP result is by no means the final judgment on a message;
regardless of the SSP result, a recipient is free to ignore that and
accept the message anyway. But when you say things like "well-known"
and "trusted" you're implying some sort of accreditation or
reputation,
even if that reputation is locally held (i.e., a white list).
SSP is about providing advice in the absence of sufficient trust to
just
accept/deliver the message. How much is "sufficient" is up to the
receiver, and may depend on the claimed author.
I'm glad to hear you say this. I think you may be assuming that this is
self-evident to people reading and/or implementing the spec, but I'd
suggest that it's much less self-evident than you may believe. At a
minimum, I think that this intent should be made much more clear within
the spec itself.
In fact, the following excerpt from the SSP spec seems to contradict
your statement above:
In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822], the verifier of a message MUST determine whether
messages from that sender are expected to be signed, and what
signatures are acceptable.
There's nothing here about "in the absence of sufficient trust to just
accept/deliver the message"... it's pretty clear that the check MUST be
made if there is no valid signature on behalf of the FROM address.
In addition, the following strongly implies that any signature from a
domain other than the Originator/From domain is inherently invalid:
In contrast, this
specification focuses on information which is relevant in the absence
of a valid signature.
I think it's important to make a clear distinction between a blanket
statement about validity of the signature, and a statement about whether
or not that signature conveys information about the policies of the
Originator domain.
[Note too that legitimate services that send emails with From: domains
outside their control are generally very careful to establish through a
confirmation step that such addresses are under the control of the email
author, so there's also a distinction between the policies of the domain
owner and the policies of individual users within that domain.]
I'd also note that the text in Section 2.8 under Suspicious implies
again that signatures other than Valid Originator Signatures are invalid
under SSP. I realize that the clause is an e.g. and not an i.e., but it
would take a pretty careful reader to catch that distinction:
Messages that do not contain a valid Originator Signature and which
are inconsistent with a Sender Signing Practices check (e.g., are
received without a Valid Signature and the sender's signing practices
indicate all messages from the entity are signed) are referred to as
"Suspicious".
And again, in Section 3:
Verifiers checking messages that do not have at least one valid
Originator Signature MUST perform a Sender Signing Practices check on
the domain specified by the Originator Address as described in
Section 4.4.
Seems to me that if you believe that reputation is primary and SSP is an
option available to verifiers who want to dig deeper, then many of these
MUSTs should become MAYs. The protocol should define how someone who
wants to perform the check can access and interpret the record, but it
should not be defining when they should make the check or what they
should be doing with the information they get back: those should both be
at the discretion of the receiver/verifier.
Using SSP as a backup if your first-level reputation check yields
uncertain results is one thing, but claiming that receivers should
automatically be invoking it any time that a signature fails to match
the
originator domain (independently of the trust status of the existing
signature) seems like it's potentially creating more problems than
it's
solving.
This is a fair point. We need some words that don't create a
normative
dependency on reputation and accreditation systems that are out of
scope. Suggestions welcomed.
Well, as above, I'd start by taking out directives as to when a verifier
MUST query the SSP record, and as to what it MUST do with the results.
It seems to me that that decision is wholly at the discretion of the
receiver/verifier, and should be keyed at least in part off of the
reputation that receiver assigns to any valid signatures that do exist.
I also don't think it's important to describe the source of that
reputation (i.e., it shouldn't be necessary to create a dependency on
any particular reputation/accreditation engine in order to make the
point).
Ellen
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html