Sorry for all the quoting but if I start snipping context and sense will
be lost.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Siegel, Ellen
Sent: Wednesday, January 23, 2008 2:37 PM
To: Jim Fenton
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Seriously.
-----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.
From my reading, I would assert that it is logical that the check MUST
be made if there is no valid signature on behalf of the from address. To
do otherwise invites abuse. You may not abuse it in your case but others
certainly will in other cases.
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.]
With regard to your bracketed comment, if the issue were only legitimate
services then there wouldn't be a need for DKIM at all. Further, there
can be no distinction - as you assert - between the policies of the
domain owner and the policies of the individual account users within
that domain. In order for the concept of domain ownership and
administration to make sense, the use of the account by the account user
at any given domain has to be considered governed by the policies
(whether publicly asserted or not)of the domain owner. If the domain
owner asserts a policy, whether through DKIM, SPF or anything else, it
has to be presumed that any use outside that assertion is not done so
with the approval of the domain owner. A receiver may choose to ignore
the domain owners assertion but then again, a receiver may choose to do
wahtever they want regardless.
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.
To say that receivers purporting to use DKIM don't have to perform a
check for SSP if there is not a valid originator signature guts the
whole notion of SSP. Why even have SSP if the expectation is that
receivers aren't going to check the purported originator if there is no
originator signature.
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).
So question for you Ellen - or anyone else (and not meant to be
snarky)..... If my company/organization chooses to assert that ALL email
sent from ag.com will be signed using DKIM and we use a strong assertion
for SPF (or anything else), are you really willing to argue that your
company should have the right to send mail purporting to be from ag.com
(in the From field) because an individual approached you to mail for
them? What if my company does it for their well known brands (which we
are working on now)? I would think that you would want to check the
policy assertions of the domain in question before you even attempt to
send on behalf of that address.
In the absence of an assertion (through whatever means, including SSP)
by a domain owner then I see no conflict with a 3rd party
sending/signing for an individual account user. In the event of a domain
making a strong assertion per the standard it would be foolish of the
standard not to require receivers to make such a check. To do otherwise
defeats the notion of a strong/strict assertion.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html