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