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

[Hector Santos]

Eric Allman wrote:
> Hector,

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

I'm not sure which part is not understood. The phrase? the usage of 
consistency? combine with fraud?

Consistency in this technical sense deals with protocol logic, it means 
that everything you measure (or get, receive) is "consistent" with what 
expected to be true.

Some definitions in the field:

- "propositions are consistent if they can all be true. A system of 
propositions can be shown to be inconsistent if it contains a 
contradiction (a proposition and its negation). Consistency and 
completeness are two key concerns of modern logic."

- "a harmonious uniformity or agreement among things or parts"

SSP-02, as I read it, does not allow a receiver or lets say removes the 
incentive to perform a consistency check because the specification 
allows for the inconsistent state to exist.

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

Well, I don't think SSP is impose any requirements on the receiver.  It 
is allowing the receiver to make the final decision with known facts 
about what is inconsistent transactions.

Most Receivers don't want any more junk than it has to take on. If it is 
told "Hey, this is junk. I don't care if you get rid of it." then what 
is the final outcome is really up to the receiver.

But just consider that you just said.  Aren't you inherently imposing 
rules on the receiver by indicating SSP should not telling what the 
receiver can or can not do?

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

Exactly, but I believe SSP-02 has removing vital information from the 
decision table, and therefore, in virtue of that decision to do this in 
SSP-02, you are negatively imposing your own rules and policies on how 
receivers should behave.

 > Hence, saying "no normative requirements for
> receivers" is in my mind just bowing to an inevitable reality.

Don't you don't you will have a SPF SOFTFAIL like consequent with SSP-02 
DKIM=ALL?

> This is at the root of eliminating the concept of 3rd Party Signatures.  

Sorry, I still don't follow the logic.  The decision is still not based 
on technical merits but subjective policy making on the receiver.

> They were only relevant in terms of how the receiver interprets the DKIM 
> results, and hence inappropriate for discussion.

Do you think everyone is going to implement DKIM as a stand-alone 
appliance "proxy" box engine where it can be fed millions of messages 
and its sole job to process these messages?

If so, then I pity the general case receivers if you believe they are 
going to tolerate such high volume overhead and abuse with little payoff 
in return.

Remember, DKIM eliminates the problem we had with SPF SOFTFAILS.  I 
believe you have stated so yourself in DKIM Media Interviews. But if you 
want results to be treated in the same way via SSP-02, people are going 
to find that, unlike SPF, just REJECTING these "softfails" is a pretty 
reliable bet

As you said, you have no control of the receivers, but you are not 
leaving them any choice either and as far as I am concern, DKIM is sure 
to come out of the gate with a thorn on its side and a black eye with 
this SSP-02 model

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

The standard track SSP protocol should have a protocol consistency check 
before you subject the system with unknown out of scope evaluators.

We had that before, now we don't and there is really no solid 
engineering logic behind the removal.

But its your bag and ball and I guess thats it.  ASP wins!  SSP is dead 
and DKIM will be isolated to a limited market but not the general case, 
where it will begin to be taken advantage of because of all the include 
DKIM forge the SSP-02/ASP people don't want receivers to worry about - 
right!


-- 
Sincerely

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