[ietf-dkim] SSP = FAILURE DETECTION
hsantos at santronics.com
Mon Sep 11 11:35:13 PDT 2006
The draft specifications, the official SSP-02, and the additional WG
document, DSAP-00, look at this as a way to verify consistency in the
signing process. It is more like a "permit" or signature authorization
concept than anything else.
I have been researching all this from an product implementation design
- Why should add DKIM signing support to our product?
- What is it going to offer customers?
- How do we sell (document) it to them so that they use it?
- Which groups of customers need it? How so?
- Where do we add it to our framework?
- How does it work with our add-on products, i.e, List Server?
- Where do we do the verification? Transport or post reception?
- How does it integrate with existing email protection technology?
- How does it tie in to existing authorization submissions?
- What is the payoff? Success vs. Failures?
- What are the loopholes?
Resigning or 3rd party signing:
- What are the reasons for resigning?
- How does resigning effect the traditional "Do not alter" passthrus?
- How does resigning effect the original signing?
- How does resigning effect verification process?
- What are the loopholes?
As much as I like DKIM with its promising proof of concept, I am not
convince its promotion has been handled correctly and it risk being damaged
and not widely adopted by incorrectly selling the idea its a transparent
Digital Message Signature (DMS) protocol "passthru" concept with vague ideas
about assigning responsibility and accountability but short on who IS
suppose to interpret these responsibility and accountability ideas, from
signer, to verifier to middle ware processes as well.
SSP to me is very simple:
At a minimum it is about confirming the physical attributes of a domain
message with or without a DMS. It is about the detecting the MOST obvious
To me, that is the BEST we can do today.
Neither SSP and DKIM-BASE can address
- near-domain phishing
- Compliant Bad Actors
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "Thomas A. Fine" <fine at head.cfa.harvard.edu>
To: <ietf-dkim at mipassoc.org>; <ietf-dkim at mipassoc.org>
Sent: Monday, September 11, 2006 11:04 AM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION
> Wietse Venema wrote:
> >Criminals switch strategy, and use look-alike domains to make their
> >mail look even more authentic than it does today.
> >If this is how SSP stops phishing mail, we have achieved nothing.
> I can NOT stop burglaries, but I still have locks on my doors. But
> SSP is BETTER than a lock:
> Currently, I can receive mail that looks exactly like it is from
> an organization that I do business with, and only through careful
> inspection can I determine that something might be amiss.
> With SSP, I can only receive mail that looks ALMOST like it is from one
> of my orgs. This is huge. This gives the user layer the ability to
> quickly, accurately, and precisely differentiate between fake and
> real messages. That's what SSP accomplishes.
> As far as what happens in the user layer, no specification can control
> that. We can certainly predict that a significant number of people
> will still fall for look-alike domains. But this is vastly different
> than people falling for the exact valid email address they were
> expecting. What are we here for if we aren't here to fix that?
> NOTE WELL: This list operates according to
More information about the ietf-dkim