Subject: [ietf-dkim] New Issue: Introduction lacks the introduction of SSP

From: "Hector Santos" <[email-masked]>
Date: Tue, 24 Jan 2006 07:44:31 -0500

I really don't like paragraph two of the introduction:

 Once the attesting party or parties have been established, the
 recipient may evaluate the message in the context of additional
 information such as locally-maintained whitelists, shared reputation
 services, and/or third-party accreditation.  The description of these
 mechanisms is outside the scope of this effort.  By applying a
 signature, a good player enables a verifier to associate a positive
 reputation with the message, in hopes that it will receive
 preferential treatment by the recipient.

If the A/R issue is out of scope, then there is no need to refer.  This
introduction has laid the groundwork as to HOW one may deem what is good
or bad - reputation.

Yet, the intro lacks any introduction of SSP which the currently the
primary mechanism to establish the assurances of the protocol as it as
discussed throughout the document as well as any threats against it. It
is the basis for much of the threat discussions, yet there is no
reference or introduction to SSP as an essential part of the protection
scheme used to address threats.

Instead, we have what is suppose to be an "out of scope" A/R discussion
throughout the document.

The truth is, it is not out of scope. A/R discussions is found
throughout the entire document as the an essential idea, technology or
what have to resolved many of the issues.

We even have a TOC index for Reputation but not SSP.  Go figure.

Doesn't make sense.  What do you guys want?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2006 13:02:51 +0000

Hi Hector,

Hector Santos wrote:
> If the A/R issue is out of scope, then there is no need to refer.  

I'm not entirely clear what you don't like there, but rather than
explain it might be easier if you could offer a better wording?

 > This

Well, that's not quite accurate. 3.2.3 is called reputation attacks
and (is one paragraph that) discusses attacks against the reputation
of someone. While that may be confusing, it has no implication at
all that a reputation system is, or is not, a reasonable counter
measure and it certainly says nothing about SSP. I'd also note that
section 4.2 is basically about SSP, even if the acronym doesn't
appear in the title.

Regards,
Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 24 Jan 2006 09:30:01 -0500

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

> I'm not entirely clear what you don't like there, but
> rather than explain it might be easier if you could
> offer a better wording?

See below.

> Well, that's not quite accurate. 3.2.3 is called reputation
> attacks and (is one paragraph that) discusses attacks
> against the reputation of someone. While that may be
> confusing, it has no implication at all that a reputation
> system is, or is not, a reasonable counter measure .....

Here is what 3.2.3 says:

| 3.2.3.  Reputation Attacks
|
|    ..... It is for this reason that reputation systems
|    must be based on an identity that is, in practice, fairly
|    reliable.

The way this sounds to me, the section provides operational guidelines
(functional specifications) for a Reputation System.

> .... and it certainly says nothing about SSP.

Exactly. Why not? When in fact, SSP can most definitely address the "joe
job" issue?  The section could say.

  SSP may play a role to address this reputation attack threat.

> I'd also note that section 4.2 is basically about SSP,
> even if the acronym doesn't appear in the title.

Right

The basic problem is that reading this document, one gets the idea that
the solution to the threats is basically a A/R system, including
explaining how it be also harmful. Quoting 4.1.5

   When reputation services are deployed, this could
   damage the originator's reputation.

A meaningless statement because we are not designing a A/R system (or
are we?).  Even then, the harm is described to occur only when they are
deployed when then fact, they are not deployed. So there is no harm. A
meaningless useless statement.

In fact, not one discussion about SSP in this section.  I would like to
know how a SSP can help or be harmful with SMR (Signed Message Replays).
Is that not the focus?

So on and so on with this document.

All in all, SSP needs to be introduced and emphasized more than A/R
currently is.  The document reeks with A/R discussions and concepts that
have nothing to do with DKIM/SSP.

hmmmmmm, one second ..... I can't believe what I am seeing....

It looks to me that the Threats Draft Intro and the SSP draft Intro are
nearly the same except the paragraph on SSP was PULLED and replaced with
A/R paragraph.  Wow!

My suggestion?

Pull the A/R paragraph and focus once again with SSP. Just put it back
from the SSP draft.   The SSP draft intro 2nd paragraph is perfect to
explain why threats might exists:

  However, the legacy of the Internet is such that not all messages
  will be signed, and the absence of a signature on a message is not an
  a priori indication of forgery.  In fact, during early phases of
  deployment it must be expected that most messages will remain
  unsigned.

Unchanged, this is perfect introduction for why they might be threats.

  However, some senders may choose to sign all of their
  outgoing mail, for example, to protect their brand name.  Such
  signers must be able to advertise to verifiers that messages claiming
  to be from them that are not signed are forgeries.  This is the topic
| for Sender Signing Policy (SSP).

Really, the whole document needs to deemphasis the unexistent concept of
A/R - it doesn't exist, there is no standard or solution yet using A/R,
and concentrate more on SSP for threat discussions - how it helps and
how it doesn't help.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2006 14:53:26 +0000

Hi Hector,

>> rather than explain it might be easier if you could

Thanks. I'll let others react to your specific suggested
text.

> (functional specifications) for a Reputation System.

I'm not so sure. I read it as saying that without DKIM any
reputation system has a big hole - and that's all I read it
as saying.

>   SSP may play a role to address this reputation attack threat.

I guess that'd be a fair sentence to add: if the domain has a
closed policy, then the recipient is less likely to "believe"
an unsigned message, in which case, SSP is I guess, helping.
Again let's see what others think.

More generally, there probably are more instances of the word
"reputation" than I noticed/recalled. But I think that in each
case the text is basically a hint that there may be something
else to be done using reputation systems, rather than a
statement that the DKIM wg will be working in that space. So, I'm
less concerned than you (clearly) but I can understand your
concern that we're giving a wrong impression overall.

It might be best if you tackle each of these as separate issues
though (suggesting better text in each case) - otherwise its quite
likely that Jim's edits might not make you happy next time 'round.
(There're only 12 occurrences of the string in the document, so
its not that much work since some of 'em are clustered.)  I'd say
its also possible that not everyone will agree with you that SSP
is the answer for all of those instances, but we'll see I guess.

Cheers,
Stephen.

---

From: <[email-masked]>
Date: Tue, 24 Jan 2006 18:53:11 -0500

>  preferential treatment by the recipient.

Once the attesting party or parties have been established, the receipient will process the message within its own established policies for such signed messages. By applying a
signature, a good player enables a verifier to assist in processing thir messages sucessfully.

thanks,
Bill Oxley
Cox