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

Eric,

I sincerely appreciate your response and I do hope you are on your way 
to full recovery from your surgery. I had a hip replacement a few years 
back and it was the first time in a long time I was forced into a 
prolonged 'vacation' from work. :-)
It been a long road to where we are now.  A road where we tuned nearly 
every stone and discussed, and even worked out.  There were some 
remaining issues, but ones that I don't believe were not addressable.
The best I can describe the concerns is that we lost the potential for 
protocol consistency fraud.
For example, you pointed out SSP-01 DKIM=ALL offered 3rd party 
signatures and this could be deemed weaker,  I agree with that point.
However, I never indicated that a VALID 3rd party was ever classified as 
secured, but the lack of one is were the power of the concept is found.
The concept is really nothing new compare to other fraud detection 
concepts, things we all do in some form or another, include SMTP.
A simple example is a traffic cop requesting and analyzing your driver 
license.  The officer is first going to make sure that the attributes 
indicated on the card matches what he sees in person. If the driver is a 
20 year old woman and the license says 60 year old man, then this among 
other thing he can compare raises a red flag.
Anything that doesn't conform to expectations is always the first thing 
people notice.  As you know, this is a basic model in lots of things we do.
In our SMTP world, an excellent example is PORT 25 and its relaxed SMTP 
compliance versus PORT 587 and its strict SMTP compliance requirements. 
 i.e, EHLO checking under port 25 is recognized as low benefit for many 
historical reasons.  Under port 587, EHLO correctness is a requirement. 
 Same with other expects between the two protocols.   In short, PORT 
587 has less tolerance towards legacy operations - by design.  You must 
login.  You must have certain headers, etc.
Even in standard SMTP port 25 operations, we have basic x822 header 
requirements that some systems may be very strict about if they don't 
exist in the DATA block or post SMTP processing. But there is no BCP for 
this.
But with DKIM/SSP we can take control of this now and not allow it to 
become yet another "relaxed" protocol.
So again, the power here is in protocol inconsistency fraud detection. 
Once things are all "compliant" then the other things comes into play, 
because there is really not much more DKIM/SSP can do from this point.
This is where other layers may come into play, including reputation 
ideas and anything else.  I never argued against reputation. I just felt 
that one group was trying to based DKIM/SSP on it only and not even 
given the SSP concept a chance.  Unfortunately, the entire process has 
been commandeered in what appears to be a strategic goal to simply water 
it down to a level of total uselessness.
So to me the idea of an Evaluator would be first a fundamental protocol 
consistency Evaluator that would be part of the DKIM/SSP framework 
across all supportive/compliant systems.  It would be 100% independent 
from any subjective or heuristics or reputation analysis or any one 
group detecting their questionable inherent policies or implementations 
methods.
It really has nothing to do with good guys vs bad guys because as we 
know, bad guys too can exhibit compliant behavior.  But that is we want 
here - we want to make sure everyone (bad and good) are all playing in 
the same field of following the basic fundamental protocol.  Just like 
we expect with other any standard client/server communications protocol.
We want this model because if we can't expect compliance with the GOOD, 
than we can't expect it from the BAD, and if we allow DKIM/SSP to become 
this, we would be back to square one of relaxed SMTP legacy transactions 
where receivers lack enforcement and know hows but more importantly has 
no new information to rely on beyond the normal level of operations to 
consider.
DKIM/SSP changes all that, this is what lead me to technology and I of 
the belief this will be a major benefit for the SMTP industry.
But this is only going to work with a standard protocol "out of the box" 
all must follow if they wish to implement it.  I think this is all 
separate from having extra evaluators (i.e, reputations, spam-assassin, 
etc).   If we start with standard relaxed higher level system, then we 
will have lost an unique opportunity we haven't had in SMTP.
Thanks


--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Eric Allman wrote:
> 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