[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section
eric+dkim at sendmail.org
Thu Feb 7 16:54:38 PST 2008
Some of what you say is correct, but other descriptions of changes in
SSP-02 don't match what we were trying to do. It may well be that we
didn't get the wording right yet.
First, a confession: most of the major changes in -02 are my doing.
In particular, I think I pushed some things onto Jim that went
further than he had wanted. I think it's unfair to ask Jim to defend
things that are basically my own responsibility. I particularly
apologize because I went in for major surgery just about the time
this was hitting the fan, and I'm not yet fully functioning.
There's a certain philosophical difference between folks on this
list. Some want SSP to be extremely specific. Others have gone on
at length that the SSP spec has no right or authority to impose its
own will on receivers. I have sympathies for both positions, but I
have to agree that there is no chance that we can successfully
dictate how receivers operate. I've said publicly many times that
receivers will simply ignore the specs if it makes their lives better
--- as we see today with intentional violations of RFC 2822. SSP-02
is an attempt to pare SSP down to appeal to the second set. Yes,
that weakens SSP, but that seems inevitable at this point. In
particular, I'm concerned that without giving receivers any guidance
on how certain situations should be handled we'll end up in a fairly
chaotic state. However, I do agree that such guidance should
probably go in a non-standards-track document.
A few specific points from your message:
--On February 6, 2008 1:46:58 AM -0500 Hector Santos
<hsantos at santronics.com> wrote:
> With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection
> against 3rd party fraud.
Speaking about SSP-02, I'm not sure how you see we've lost that
"protection". In -01, DKIM=ALL specifically allowed 3PS (Third-Party
Signatures), so arguably it was weaker before. Under SSP-02, a
receiver could decide that 3PS should be treated more harshly (where
"more harshly" doesn't necessarily mean "discard" --- it could just
mean do content scanning on the message).
We did remove all discussion of 3PS. The extended list discussion
around them made it clear that we just don't have enough operational
knowledge at this time to understand how they should work. As such,
we are now leaving all interpretation of 3rd party signatures up to
the receiver. That doesn't mean we've necessarily lost the ability
to handle 3PS in a distinct way, but it will have to go into another
document, at least for now.
> The NEVER concept can still be covered using DKIM=DISCARDABLE and a
> NULL DKIM public key.
> The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
Except that DISCARDABLE doesn't prohibit 3PS. It doesn't even say
that messages without any signatures MUST or even SHOULD be
discarded. All it says is how the purported author domain views the
messages that it sends out. The furthest it goes is to say that the
purported Author Domain "encourages the recipient(s) to discard it."
> But anything related to 3rd party signers was completely eliminated
> in SSP-02/ASP. Even though SSP-02 DKIM=ALL is a "always sign for
> 1st party authors" concept, it is basically a DKIM=DISCARDABLE
> without semantics on REJECTION. DKIM=DISCARDABLE failures is
> explicit with the REJECTION control. DKIM=ALL failures are not.
SSP-02 DKIM=ALL is not a "always sign for 1st party authors" concept.
It doesn't even mention first parties, any more than it mentions 3rd
parties. All it says is "when the message left my control, I had
signed it." It says absolutely nothing about how the receiver should
handle the message.
Similarly, and as noted above, DKIM=DISCARDABLE makes no normative
assertions about what the receiver should do with the message. It is
impossible to say anything about when the receiver should reject
messages without stepping into the forbidden territory of forcing a
certain behavior on the receiver.
> In short, DKIM=ALL is the SPF version of SOFTFAIL where you can
> record it, but you do not take any REJECTION action on it. Just
> like SPF.
There's nothing that prevents the recipient from rejecting messages
under a DKIM=ALL condition. In fact (if we did it as intended) there
is no normative language anywhere in SSP-02 about how the receiver
should process messages, be they signed, unsigned, or 3PS.
> But that is not the case with DKIM. Here we have 100% detectable
> fraud capabilities that is unrelated to legitimate multiple hope IP
> issues and ASP is mandating a flawed inherent policy that RECEIVERS
> should ignore certain kinds of obvious fraudulent messages.
I'm not speaking to ASP, but SSP-02 makes (or is intended to make) NO
normative restrictions on when the receiver should accept or reject
Another addition to SSP-02 was the concept of the Evaluator. This
was added purely to try to make it clear that SSP is merely one input
into the decision process. The Evaluator decides whether to reject a
message, quarantine it, do additional content scanning on it, accept
it without further scanning, redirect it to the FBI, post it on
USENET, or anything else it cares to do. My hope was that creating
an explicit entity that makes the decision and clearly declare it out
of scope we would clarify the limits of SSP.
It is my sincere hope that we will quickly gain enough experience
that new documents can be produced providing further guidance (not
requirements) for how the Evaluator should interpret SSP for broadest
More information about the ietf-dkim