[ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8

[Eric Allman]

Hector,

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 
any messages.

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

eric