Subject: [ietf-dkim] The (really) latest SSP draft

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Sep 2007 15:25:40 -0700

The list has been uncharacteristically silent since I submitted an
update to the SSP draft 10 days ago, so I thought I'd point out the new
draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more
complete info on the changes are in section B.1).

The most significant change is a new tag, called "handling", that
represents what I called the SSP "Strong" Option in my presentation at
IETF 69.  As I mentioned at the time, we needed a better word than
"strong", and this is what Eric and I came up with.  It takes one of two
values:  "process", the default, means to do what you would normally do
with a message that is Suspicious.  "block" is a way for a domain to
express the preference that messages violating SSP be dealt with more
harshly, such as by deleting, bouncing, or rejecting them.

Section 5, "Third-party Signatures and Mailing Lists", has been removed
since it belongs better in the Overview document(s).  Note to overview
authors:  hint, hint.

Most of the other changes in the document, which are numerous, are to
tighten up the wording rather than to introduce anything new or
different.  For example, when user-granularity SSP was in the document,
SSP applied to an "entity" which was either a user or a domain.  the
word "domain" is sufficient, and clearer, now.

Comments appreciated as always!

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Sep 2007 15:44:10 -0700

Step 9 of the SSP lookup algorithm sez:

   9.   If the value of the SSP "dkim" tag is "all", and one or more
        Verifier Acceptable Third-Party Signatures are present on the
        message, the message is not Suspicious and the algorithm
        terminates.

I don't see the motivation for this, and it's definitely not in the 
requirements. A
receiver is always completely at liberty to whitelist, blacklist, greylist,
pink-polka-dotted-list a third party signature regardless of what the 
originating
domains says. What unique value does a signer bring to an across the board
statement about all third party signatures? I can't think of a single 
use case that I'd
alter processing based on that information.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Sep 2007 15:52:29 -0700

Here you mention that "one or more valid SSP records". In later steps (7?)
you don't subsequently say which record to choose if there is more than
one. I suppose that the first one is as good as any, but it should at 
least be
explicit.

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Sep 2007 15:57:24 -0700

The key words here are Verifier Acceptable.  The verifier gets to
specify which signatures are Verifier Acceptable, which gives it
precisely the liberty you describe.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Sep 2007 15:59:33 -0700

Agreed.  Hence the note immediately before the Table of Contents:

> (Unresolved Issues/To Be Done)
>
>    Need to consider handling of multiple responses to a DNS query for
>    the SSP record.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Sep 2007 16:05:20 -0700

> precisely the liberty you describe.

We're not communicating. What might a receiver do differently with a third
party signature with and without the "all"? I can't think of anything.

Also: there are two orthogonal things going on with "all": the general 
proposition
from the originator that they sign everything, and this third party 
signature thing.
At the very least, they should be decoupled.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Sep 2007 11:49:28 +0100

> harshly, such as by deleting, bouncing, or rejecting them.

I guess this isn't something that's explicitly covered in the
requirements draft, so I think we need to see if folks want the feature
supported or not. (Thanks for highlighting it Jim.)

So, do we want to allow ssp statements to say "handling=block" or
some equivalent?

S.

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Sep 2007 10:48:26 -0700

> We're not communicating. What might a receiver do differently with
> a third party signature with and without the "all"? I can't think
> of anything.

You're forgetting the "strict" case.

Without step 9, the algorithm would fall through to step 10 ("The 
message is Suspicious and the algorithm terminates").  Step 9 
explicitly allows the third party signature in the "all" case, but 
not in the "strict" case.  Note that the valid first party signature 
case was handled in step 1, and the "dkim=unknown" case was handled 
in step 8, so by step 9 we're down to either no valid signature or a 
valid third party signature, and a dkim tag of "all", "strict", or 
something else due to a malformed SSP record.

It might be easier to understand (and nearly semantically equivalent) 
if steps 9 and 10 read:

9.  If the SSP "dkim" tag is "strict", or if no Verifier Acceptable 
Third-Party Signatures are present on the message and the SSP "dkim" 
tag is "all", the message is Suspicious and the algorithm terminates.

10.  The message is not Suspicious and the algorithm terminates.

eric

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Sep 2007 12:14:23 -0700

Eric Allman wrote:
> explicitly allows the third party signature in the "all" case, but not 
> in the "strict" case.  Note that the valid first party signature case 
> was handled in step 1, and the "dkim=unknown" case was handled in step 
> 8, so by step 9 we're down to either no valid signature or a valid 
> third party signature, and a dkim tag of "all", "strict", or something 
> else due to a malformed SSP record.
>

The main problem I'm having is tying "all" to third party signatures 
whatsoever.
The requirements make no mention of "all" being tied to them, and I -- 
again --
don't see what the value is for the _originator_ to make any statement 
about them.
"All" is a function of the originator's practices alone. Whether a 
useful (to the receiver)
third party signature is tacked on in transit is completely out of its 
hands.

          Mike

---

From: Eric Allman <[email-masked]>
Date: Sun, 30 Sep 2007 13:13:11 -0700

It sounds like you are arguing that "all" should be "strict" and 
"strict" should be eliminated; as a corollary, no Third Party 
Signatures should be accepted under any circumstances.  That's a 
valid argument, but it has nothing to do with whether the -ssp draft 
is accurate.

I note however that -ssp-requirements doesn't seem to cover the Third 
Party Signature case at all.  Section 2 defines "Third Party 
Signature" but then never uses the term.  In fact, although the one 
line description of Problem Scenario 1 reads "Is All Mail Signed with 
DKIM?", and section 4.1 seems to cover the case of a Third Party 
Signature (at least, it doesn't mandate a First Party Signature), 
sections 2 and 5.3 point 3 define "DKIM Signing Complete" as 
requiring a First Party Signature.  In short, it appears that -req 
doesn't permit third party signatures under any circumstances.  I'm 
not sure this was the intent of the working group.

Reading the documents in this light, it's pretty clear that -ssp and 
-req are in conflict.  The WG needs to decide on which way it wants 
to go.

eric

--On September 30, 2007 12:14:23 PM -0700 Michael Thomas 
<[email-masked]> wrote:
> The main problem I'm having is tying "all" to third party
> signatures whatsoever. The requirements make no mention of "all"
> being tied to them, and I -- again -- don't see what the value is
> for the _originator_ to make any statement about them. "All" is a
> function of the originator's practices alone. Whether a useful (to
> the receiver) third party signature is tacked on in transit is
> completely out of its hands.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Sep 2007 13:39:44 -0700

Eric Allman wrote:
> "strict" should be eliminated; 
> as a corollary, no Third Party Signatures should be accepted under any 
> circumstances.  That's a valid argument, but it has nothing to do with 
> whether the -ssp draft is accurate.

No. Strict seems consistent with the requirements.  For "all", the 
problem I'm
having is tying the statement "I sign everything" to any other statement,
including "I think that 3rd party signatures are groovy". They are not 
inherently
linked, and the SSP draft shouldn't do that. I can very easily say "I 
sign everything"
and have no opinion whatsoever about other kinds of signatures.
> sections 2 and 5.3 point 3 define "DKIM Signing Complete" as requiring 
> a First Party Signature.  In short, it appears that -req doesn't 
> permit third party signatures under any circumstances.  I'm not sure 
> this was the intent of the working group.

It doesn't permit 3rd party signatures for _SSP_ itself. That doesn't 
say anything
about third party signatures in general which receivers are perfectly at 
liberty to
use or not use as they see fit. I'm pretty sure we've been through this 
ad nauseum
about third party signatures with SSP and that the consensus was that we 
didn't
want to go there. Look at the archives about whether we needed 
enumerated lists
of 3rd party signers for example -- that was rejected.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Sun, 30 Sep 2007 20:11:28 -0400

Michael Thomas wrote:

> say anything about third party signatures in general which receivers 
 > are perfectly at liberty to use or not use as they see fit. I'm pretty
 > sure we've been through this ad nauseum about third party signatures 
with
 > SSP and that the consensus was that we didn't want to go there.

No. There was no consensus. Major difference.

 > Look at the archives about whether we needed  enumerated lists

No, for all intent and purposes, it was never given a chance because a) 
this key cogs never understood it, b) was confused by other REPUTATION 
designs ambitions and c) due to some wasted requirements document molded 
by a person who never believed in strict 3PS designs in the first place.

No one should be surprise that the same critical issues highlighted 
nearly 3+ years ago is the same issue today.  It can't be ignore and I 
have serious doubt DKIM will be seriously adopted in mass because 3PS 
was neglected and never adequately and seriously accepted for 
consideration by its cogs.  Unfortunately, the decision was made to 
IGNORE those who have good and excellent input. So no, there was never 
never any serious consideration, thus any valid consensus one way or 
another.

-- 
Sincerely

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