I think we need to organize the use cases differently. We need to do a
differential use case analysis.
We have two essential classes of message: Genuine and Fake.
FOR DKIM BASE:
We have three possible outcomes: Definitely Genuine, Definitely Fake and
Undetermined
[We can if people think there is value further break down Undetermined
according to probability but bear with me]
A proposed processing algorithm is BROKEN if it it generates the outcome
Definitely Genuine for a Fake message or Definitely Fake for a Genuine Message.
So we have a set of use cases that describe 'good behavior' and a set of use
cases that describe 'bad behavior and we have evaluated DKIM base against them.
As it happens due to the vagaries of the Internet there is (almost) always the
possibility that a failed signature verification is due to network operator
error or mangling by an intermediary so the only two outcomes from the DKIM
system are Definitely Authentic and Undetermined.
To look at policy we have to look at a wider scope. Policy is not an input to
DKIM it is an input to the system which uses DKIM, a system that will
inevitably use some form of authorization input, in our terminology
'reputation'.
The outcome from the Authentication backed reputation module has the following
values:
Definite Accept, Definite Reject, Further Processing
In this case we do want to distinguish between different further processing
outcomes. In particular we want to use guidance from the domain name owner,
i.e. policy to guide the further processing that takes place. A message that is
NOT compliant with the guidance from the domain name owner SHOULD be treated
less favorably that a message that is.
The outcome from the Authentication backed reputation module thus has the
following values:
Definite Accept, Definite Reject, Compliant, Not Complaint
The objective of the design of the policy language is therefore to allow the
creation of the most accurate processing algorithm, that is the one which
assigns the most desirable outcome in the highest proportion of cases without
assigning an undesirable outcome.
That is a processing algorithm that assigns definite accept to a fake message
is broken and must be rejected.
We need to order the use cases according to the acceptable and the desirable
outcomes. Then evaluate the processing algorithms according to their ability to
correctly assign outcomes to the use cases.
This is the differential use case analysis.
I am constructing a matrix with the outcomes for my processing algorithm and
the best algorithms I can construct for the Fenton proposal. Its on paper at
the moment and I can't spread it out here on the plane. So should have it on
Monday or so.
-----Original Message-----
From: ietf-dkim-bounces(_at_)dkim(_dot_)org
[mailto:ietf-dkim-bounces(_at_)dkim(_dot_)org] On Behalf Of Stephen Farrell
Sent: Monday, November 13, 2006 5:01 PM
To: Steve Atkins
Cc: ietf-dkim WG
Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements
Steve Atkins wrote:
Well, I believe the list is wrong, however it isn't my
list, it's the
list in dkim-ssp-requirements-02.
4.1. Problem Scenario 1: All Mail Signed with DKIM
4.2. Problem Scenario 2: Illegitimate Domain Name Use
4.3. Problem Scenario 3: Domain Sends No Mail
Good. You have read the draft.
In that case I'm sure you'll agree that we can best progress
if we deal with what's in there and not with some re-wording
that (with this list on this topic), amounts to starting over.
My problem is not with your or the draft's list. It is with
the endless wandering about in the wilderness that this
thread represents. (If it was a bit unfair to jump on your
message, then I'm sorry but I've now seen this entire
discussion fizzle out enough times that I'm not very tolerant of it.)
I look forward to you raising an issue against the -02 draft
saying how you'd like to fix section 4. Please do that in a
new thread.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html