ietf-dkim
[Top] [All Lists]

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

2008-02-07 18:03:51
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(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>