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

[Eric Allman]

Hector,

I have to admit that I'm having a bit of problem understanding 
everything you are saying in your response, perhaps because I haven't 
been able to get through the nearly 500 messages that came in while I 
was recuperating.  I finally concluded that I had to just jump in, 
but I am missing some context.

Thanks for your example on SMTP vs SUBMIT --- that gives me a good 
handle on what you mean by "relaxed protocol".  But I'm not 
understanding "protocol consistency fraud".  I think they are 
connected, but I don't understand how, and how SSP-02 makes it easier 
vs. SSP-01.

So far as I am aware, the SSP-02 /protocol/ is no weaker than in 
SSP-01.  What is weaker normative requirements on how the receiver 
interprets that protocol, which is inevitable if you buy into the 
idea that SSP has no right to impose any requirements on the 
receivers.  If you're disagreeing with that premise then I fully 
understand; this is just a case where you have to choose one and go 
with it, because you can't have it both ways.  As I said before, my 
position is that as desirable as it may seem to put requirements on 
the receiver in order to guarantee consistent results, the reality is 
that the receivers will do whatever they want to in order to give the 
best results for themselves and their customers.  Hence, saying "no 
normative requirements for receivers" is in my mind just bowing to an 
inevitable reality.

This is at the root of eliminating the concept of 3rd Party 
Signatures.  They were only relevant in terms of how the receiver 
interprets the DKIM results, and hence inappropriate for discussion.

You say some things about the Evaluator that lead me to believe that 
you've got a different idea of what it should be than I do.  You say:

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

This is the inverse of the model in my head, where the Evaluator is 
completely /dependent/ on "subjective or heuristics or reputation 
analysis" --- it is, in short, how the receiver decides how to 
process the message.  Indeed, the point of introducing the concept is 
an attempt to make explicit what is out of scope for normative 
definition in the SSP spec.

If I'm misunderstanding what you are trying to say (very possible) 
then I apologize and request further explanation.

eric



--On February 8, 2008 6:28:05 AM -0500 Hector Santos 
<hsantos at santronics.com> wrote:

> 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