Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to
implement or use
except in a few specific cases like highly phished sites."
There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that
discussion
in the past it's not gone anywhere productive
Personally, I think that exact question has been asked many
times and answered
with great specificity many times. I agree that those who
disliked SSP at
the start of the working group still disagree on this.
+1: neither the irresistible force nor the immovable object are budging
:)
Personally, I think only the highly phished sites that really
care about
forgery will publish highly restrictive SSP records and so I
think Bill and I
actually agree.
Steve thinks a threat model and attack tree are necessary. I don't know
if they are necessary or if this work has been completed. My
justification for SSP is the same one that has been brought up for
almost two years now: after certain domain-owners go to great lengths to
deploy DKIM reliably across their entire extended set of legitimate
MTAs, they will want to tell the world their non-binding preference is
to have receivers not deliver unsigned messages using their domain.
I know of significant market demand for this capability and I certainly
have every plan to use it if/when available across a very large number
of mailboxes worldwide.
Note that this capability doesn't mean that the current SSP draft is
"right" let alone "perfect". But whatever wordsmithing and improvements
are made to SSP it is important that the core of the strict/deny
capabilities remain. I'm very much in favor of polishing SSP and very
much opposed to removing core strict/deny features.
The choice in my mind is whether something like SSP is
decided in secret among
large highly phished senders and large receivers or if we are
going to have a
standardized approach that all can use IF they wish. As has
recently been
said, no one is forcing anyone to use SSP. Those who don't
like it are
perfectly free to ignore it.
Yahoo and Paypal have already publicly stated that they have developed
their own back-channel method for a strict/deny-like SSP capability for
DK. Other large senders have also said they will obtain this
functionality through back-channel arrangements if needed.
Here is the quote Bank of America provided for use at IETF:
"DKIM has allowed the largest targets of online fraud and phishing, the
financial services industry, to begin positively asserting e-mail that
is legitimately from them. Conversely, we are looking toward SSP as a
way to apply strong policy regarding e-mail that falsely purports to be
from one of our domains. In other words, this policy framework needs to
provide a clear intent related to the assertion of the sending
institution, including a strong capacity for dealing with unsigned mail
or malformed signatures, including the intent for this type of message
to not be delivered to the customer mailbox.
If this capability is not available in SSP, then the capability will be
provided by other means and SSP will lose much of its usability."
Erik M. Johnson, SVP, E-mail Infrastructure & Secure Messaging, Bank of
America
Here is the quote from US Bank:
"Delivering an email that has failed a DKIM check as "Suspicious" may
fit most use cases but not all. Domains that are targeted for Phishing
need a mechanism of informing recipient domains that they have "no
confidence" in unsigned or improperly signed email. These emails should
be treated as potential threats and NOT delivered to the Intended
recipients. A SSP "Deny" option would provide the ability for domains
that fit this use case to recommend rejecting or quarantining email that
has failed DKIM verification."
Jeff Carnahan, Messaging Solutions Architect, US Bank
Note 1: Please don't misinterpret these statements as requesting the
ability for senders to *dictate* receiver behavior.
Note 2: Please don't misinterpret these statements which use the term
"phishing" as statements that DKIM and/or SSP will solve "phishing". The
use of the term "phishing" is clearly intended to help describe the
types of institutions that are more interested in this type of
capability, not to describe the problem we are solving.
Note 3: I believe Bank of America and PayPal have two of the largest,
most sophisticated enterprise deployments of DK/DKIM in the world. These
two organizations requests for this capability should not be taken
lightly. Even if one disagrees with their request it is dangerous for
the IETF to deny a requested capability the Internet community.
cheers,
pat
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html