----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]>
> 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
