ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP = FAILURE DETECTION

2006-09-11 11:41:03
Thomas,

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
feasibility standpoint.

Original Signing:

 - 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?

Verification:

 - 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?

Etc, etc.

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
of failures.

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.
http://www.santronics.com



----- Original Message -----
From: "Thomas A. Fine" <fine(_at_)head(_dot_)cfa(_dot_)harvard(_dot_)edu>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>; <ietf-dkim(_at_)mipassoc(_dot_)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?

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



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

<Prev in Thread] Current Thread [Next in Thread>