Subject: [ietf-dkim] NEW ISSUE: Simplify SSP decision tree

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:57:39 -0800

>> 4.4.  Sender Signing Practices Check Procedure
...
>>    1.   If a valid Originator Signature exists, the message is not
...
>>    2.   The Verifier MUST query DNS for a TXT record corresponding to
...
>>    3.   The Verifier MUST query DNS for an MX record corresponding to
...
>>    4.   If the immediate parent of the Originator Domain is a top-level
...
>>    5.   The Verifier MUST query DNS for a TXT record for the immediate
...
>>    6.   If the SSP "t" tag exists in the response and any of the flags
...
>>    7.   If the SSP "t" tag exists in the response and any of the flags
...
>>    8.   If the value of the SSP "dkim" tag is "unknown", the message is
...
>>    9.   If the value of the SSP "dkim" tag is "all", and one or more
...
>>
>>    10.  The message is Suspicious and the algorithm terminates.
>>
>>    If any of the queries involved in the Sender Signing Practices Check
>>    result in a SERVFAIL error response, the verifier MAY either queue
>>    the message or return an SMTP error indicating a temporary failure.
> 
> This is a fairly complex decision tree, for an initial specification of a new
> type of protocol. 

The first version of SSP that is standardized needs to have a much shorter and 
simpler decision tree, if interoperable deployment is to be achieved anytime 
soon after publication.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 09 Dec 2007 14:49:46 -0600

> The first version of SSP that is standardized needs to have a much 
> shorter and simpler decision tree, if interoperable deployment is to be 
> achieved anytime soon after publication.

Although I'm all for simplification, I wouldn't worry much about this 
issue.  10 steps is hardly a crucible.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 14:49:55 -0800

Arvel Hathcock wrote:
>> shorter and simpler decision tree, if interoperable deployment is to 
>> be achieved anytime soon after publication.
> 

For Internet-scale adoption, this type of complexity can be fatal, 
particularly when it pertains to a level of policy communication for which 
there is no precedent.

Well, ok, other than SPF -all... from which we ought to learn some lessons.

d/

-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 9 Dec 2007 23:36:03 -0500

> Well, ok, other than SPF -all... from which we ought to learn some lessons.
Yes.  And in my experience, as one of the leaders of the SPF project, the 
biggest mistake that was made in RFC 4408 was to not be more explicit about 
sender expectations or preferences.  Many times I've been involved in 
discussions with large recievers about SPF receive processing.  I regularly 
hear concern about rejecting mail, "Because the RFC doesn't explicitly say 
that's the expected action".

So, from someone who has actually worked on that particular project and not 
just had a lot to say about it, there is a definite lesson to be learned, 
although probably not the one you were thinking of.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 08:33:47 -0800

> although probably not the one you were thinking of.

   Part of the problem is that "softfail" and "hardfail" don't make
   much intuitive sense. If we're going to use english terms, they
   better be *very* close to the dictionary meaning otherwise they'll
   be misconstrued. I, for one, was not in favor of english words for
   the practices as it would force the implementor to actually read
   what the draft said, rather what they could intuit from the natural
   language definition.

		Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 10 Dec 2007 11:41:17 -0500

On Monday 10 December 2007 11:33, Michael Thomas wrote:
> > biggest mistake that was made in RFC 4408 was to not be more explicit
> > about sender expectations or preferences.  Many times I've been involved
> > in discussions with large recievers about SPF receive processing.  I
> > regularly hear concern about rejecting mail, "Because the RFC doesn't
> > explicitly say that's the expected action".
> >
> > So, from someone who has actually worked on that particular project and
> > not just had a lot to say about it, there is a definite lesson to be
> > learned, although probably not the one you were thinking of.
>
Agreed.  The larger problem is that RFC 4408 says receivers can use a Fail 
result for filtering or reject the message (so it isn't clear what senders 
were expecting).  Having one determined set of actions for one set of 
circumstances to be compliant with the spec is very useful in my experience.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 09:02:39 -0800

> circumstances to be compliant with the spec is very useful in my experience.

   I have a lot of hesitation here because advocating a particular
   message disposition given a single data point is usually
   a bad idea. Maybe SSP -- like gross filtering at 2821 connect
   time with DNSBL's and friends -- is like that, maybe it isn't.
   I'd rather let the people whose day jobs live and die by the
   false positive/false negative ratio make that call. My feeling
   is that if we put any advice in at all, it should be a
   non-normative discussion of what the sender would prefer or
   something like that.

   Which isn't at all to diminish your experience. This is tough
   because it's a wide ranging audience.

		Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 18:12:39 +0100

Michael Thomas wrote:

> much intuitive sense.

For SPF (and Sender ID) a SOFTFAIL is what SSP has as t-flag, and
an Authentication-Results: hardfail is just a FAIL (for SPF etc.).

For receivers accepting "hardfail", not exactly the ideal course,
but receivers are free to shoot into their own foot.  Aim higher.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 11:30:15 -0800

> but receivers are free to shoot into their own foot.  Aim higher.

Well, FWIW, I don't think that t=testing is at all helpful either. What,
for example, does p=strict, t=testing mean? It seems like a silly-state
to me and ripe for confusion. It's that sort of subjective state that we
should both learn from SPF and avoid.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 11:47:26 -0800

> should both learn from SPF and avoid.

+1.

d/

-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 22:14:27 +0100

Michael Thomas wrote:

> FWIW, I don't think that t=testing is at all helpful either.

+1  It also muddies the water for the Authentication-Results,
if they map e.g. "strict deny" to "hardfail" and "all process"
to "softfail" there's nothing left for any "strict testing".

> It's that sort of subjective state that we should both learn
> from SPF and avoid.

Yes, IMO the SOFTFAIL "testing" wasn't a good idea, one of the
many SPF battles I lost.  Some folks really like it, a FAIL is
a difficult decision for the known reasons wrt SPF or PRA.

A "strict deny" SSP is also a difficult decision.  But this
"testing" loohole doesn't help receivers, a sender policy (or
a published signing practice) must make sense for *receivers*.

 Frank

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 10 Dec 2007 21:14:28 -0600

> Well, FWIW, I don't think that t=testing is at all helpful either. 

+1

And it will help lower the 10 steps to something less which, if this is 
necessary at all, would be a good thing.

Arvel

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 11:57:54 -0800

On Dec 10, 2007, at 11:30 AM, Michael Thomas wrote:

> What,

+1

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2007 12:29:43 -0800

Hopefully not adding to the noise, but I've seen about 5 people +1
my suggestion that t=testing should go.

	Mike

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 11 Dec 2007 15:31:31 -0500

Jon Callas wrote:
>> What, for example, does p=strict, t=testing mean? It seems like 
 >> a silly- state to me and ripe for confusion. It's that sort
 >> of subjective state  that we should both learn from SPF and avoid.
> 
> +1

+1. Get rid of it.

For the record, I believe I raised this issue a few times over the past 
few years, as I did with the SPF group.  To accommodate those who might 
want to keep it, I proposed that it be time limited consideration.

Since its only a concept that applies for "beta testing" or "migration", 
that is has to be a time limited operation.   So if anyone sees a test 
site using DKIM, it should probably record this and track its usage.

Otherwise, IMO, +100, get rid of it.

-- 
Sincerely

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

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 11 Dec 2007 22:45:59 -0500

+1

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Dec 2007 20:01:02 -0800

> be achieved anytime soon after publication.

This reminds me of the famous line in the movie "Amadeus": "...there are
simply too many notes, that's all.  Just cut a few and it will be perfect."

The length of the decision algorithm (not really a tree) is determined
by the functionality that WG consensus decides upon.  If we decide to
eliminate some functionality, such as the "testing" flag, the decision
algorithm can be made simpler.  However, simplification of the decision
algorithm is not a suitable issue itself; it's something that may happen
as a result of other decisions made by the Working Group.

-1 to this as an issue.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Dec 2007 20:04:58 -0800

+1 from me too, except that we should just remove it from the draft
rather than deprecate it.

-Jim

---

From: Mark Martinec <[email-masked]>
Date: Wed, 12 Dec 2007 11:41:21 +0100

> rather than deprecate it.

I very much agree, testing in SSP should go.

If it weren't too late, I'd say the same for t in DKIM-base public keys.
It turns out that for most signers a feeling of a safety net (however thin)
gives them some comfort - or covers implementers' butt from their boss,
so they keep their t forever. As a consequence, recipients are forced
to purposely violate DKIM base and just ignore t in a public key, otherwise
they'd be stuck for years with processing signatures which turn out
can not be enforced due to 't'. So even if it initially appears 'testing'
may have some value, in practice it doesn't, and just adds to confusion.
I think this pretty much applies to t=y in SSP as well.

  Mark

---

From: Damon <[email-masked]>
Date: Wed, 12 Dec 2007 10:01:07 -0500

+1.

 Enough +1's on this one?

Regards,
Damon Sauer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 06:20:02 -0800

> simply too many notes, that's all.  Just cut a few and it will be perfect."

Jim,

Were my suggestion equally whimsical, the Amadeus reference would be apt and 
possibly even clever

Unfortunately, it was based on extended observation of what seems to deploy 
and get used, versus what does not.

> by the functionality that WG consensus decides upon.  If we decide to

You are expressing a view that means that there are no other forces than wg 
consensus that affect the success of a protocol, and I suspect we all know 
that is not true.

Each of the many OSI protocols represented working group consensus.  (For 
those who have not had the delightful experience of attending such meetings, 
they work on unanimity, not rough consensus.  In other words, they set the 
filter bar higher than the IETF...)

IPv6 represented working group consensus, yet it produced something that has 
yet to gain critical mass in 15 years.

And so on.

Complexity and strong *market* consensus (ie, market pull) about what is 
needed are fundamental forces affecting protocol success.  As for complexity, 
I specifically cited challenges in reaching high levels of interoperability.

> as a result of other decisions made by the Working Group.

Complexity of design and its impact on interoperability is not a "suitable 
issue"?  Wherever did you get that view from, Jim?

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Dec 2007 15:38:37 +0100

Dave,
>
> IPv6 represented working group consensus, yet it produced something
> that has yet to gain critical mass in 15 years.

First, I think we are far afield if we are simply arguing about whether
working group consensus is necessary but not sufficient for protocol
success.  Procedurally that is what we have to work with.  Right?

More to your text above, there are many factors as to why IPv6 is not
broadly deployed.  The simplest factor, however, has nothing to do with
complexity OR functionality: it's simply cheaper to not change
operationally until it's not.  That is- economics has had, is having,
and will have its day.  This means that we are on curves that may yet
well lead to broad IPv6 deployment.  This would all be irrelevant but
for the fact that you raised an example that I believe will turn into a
counterargument to the one you are making Real Soon Now.
> Complexity of design and its impact on interoperability is not a
> "suitable issue"?  Wherever did you get that view from, Jim?

We're down to a basic Occam's Razor discussion.  What functionality do
you wish to eliminate that makes the state machine simpler, and does
that make the solution to the problem we are attempting to solve simpler
than is possible (meaning are we no longer solving the problem we agreed
to solve) and is there an issue open on that?  Absent that issue, what
does it mean to simplify?

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 07:17:28 -0800

> success.  Procedurally that is what we have to work with.  Right?

Right.  We don't have to wrry about the braoder IETF community taking 
exception, the Security area shooting holes, or AD Discusses.  And heaven 
knows, we don't have to worry about actually market uptake of our output or 
whether the protocol actually works.

> operationally until it's not.

Quite a few people consider the feature-bloat of IPv6 and its incompatibility 
with IPv4 to have been critical barriers to adoption.  Were IPv6 made a fairly 
minor upgrade to v4, then its initial adoption would have been a fairly minor 
upgrade to existing software.

> to solve)

Yup.  Nicely said.

One wrinkle is that it's clear different people are trying to solve different 
problems.  This exercise is often useful to uncovering incompatible goals.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Dec 2007 09:17:52 -0800

Dave Crocker wrote:
> Were my suggestion equally whimsical, the Amadeus reference would be
> apt and possibly even clever
>
> Unfortunately, it was based on extended observation of what seems to
> deploy and get used, versus what does not.

Forgive my attempt to insert a bit of levity into the discussion.   We
mustn't have any of that.
> You are expressing a view that means that there are no other forces
> than wg consensus that affect the success of a protocol, and I suspect
> we all know that is not true.
>
> Each of the many OSI protocols represented working group consensus. 
> (For those who have not had the delightful experience of attending
> such meetings, they work on unanimity, not rough consensus.  In other
> words, they set the filter bar higher than the IETF...)
>
> Complexity and strong *market* consensus (ie, market pull) about what
> is needed are fundamental forces affecting protocol success.  As for
> complexity, I specifically cited challenges in reaching high levels of
> interoperability.
>
>

Complexity is clearly relevant, and should be a consideration in
everything we do.  My point about this particular issue is that it's
seeking to do something about the dependent variable (the number of
steps in the algorithm) while we should be dealing with this at the root
cause (e.g., removal of the testing flag).

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 12:04:10 -0800

Jim,

Well, since I did say that it would have been clever if it had been on point, 
I'm certainly not one to object to attempts at humor.

However given the list's long history of seeking to reject challenging 
questions through overt or passive aggressive hostile dismissals, forgive *me* 
for thinking that this was merely one more such note added to the wg soup.

Again, note that the remainder of your note was, indeed, a dismissal of my 
concern, declaring concern over complexity, by itself, as out of scope.

> cause (e.g., removal of the testing flag).

It appears that you are distinguish between symptom and cause, which is always 
useful.  But it also appears that you are taking exception to my noting a 
symptom that I view as correlating well with a problematic cause.  That, I 
guess, is where we differ.

d/
-- 

   Dave Crocker