----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
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.
We even have a TOC index for Reputation but not SSP.
Go figure.
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org