Re: [ietf-dkim] Re: Discussing what someone said about SSP - productive?

Hi Steve,

Version 1.0 of my response to you here was rather terse. Version 1.1 
cleaned it up. Version 2.0 reduced it down to just answering your last 
question, and this version 3.0 is what ended up with which I hope can 
serve as mush shorter outline. I just hope that the reduction and 
removal of more complete insights and reasoning doesn't water down the 
key points:
  o A/R Out of Scope.
  o SSP is not about A/R.
  o SSP addresses DKIM protocol consistency.
  o SSP does not address Phishing.
  o Concern: Discovery Process.
  o Concern: # of lookups required.
  o Concern: 3rd party usage
  o Concern: Mailing list usage

o A/R Out of Scope.

A/R (Accreditation/Reputation) concepts is out of scope. I will just 
like to note that this on-going A/R injection only served to be a source 
of contention and continues to defuse the SSP working group efforts.
There are endless reasons why it is out of scope, both technically and 
very much political.  Even then, A/R does not solve the problem SSP 
attempts to address.
Since A/R concepts is out of scope, I will only say that it is already 
viewed that it may be an additional layer in a total solution framework, 
but it is not a requirement for DKIM.
o SSP is not about A/R.
o SSP addresses DKIM protocol consistency.

SSP is not a reputation concept. It does not apply to who is GOOD or 
BAD. It applies to all.  SSP address the protocol consistency of the 
DKIM usage.  It looks at all the possible outcomes and which one can be 
protected from exploitation.  It applies to all - good and bad. The bad 
can be DKIM/SSP compliant as well.   This is where A/R layer may apply 
but it is not a part of the protocol consistency requirement SSP addresses.
o SSP was never designed to address Phishing.

SSP only address DKIM protocol consistency. It is not an ANTI-SPAM 
concept in the sense it is making the 'subjective decision' of whats 
good or bad or what "appears" to be bad with phished domains.  Phished 
domains are not addressable with SSP and for the record, A/R concepts 
can not adequately address it as well.
o Concern: 3rd party usage.
o Concern: Mailing list usage.
o Concern: Discovery Process.
o Concern: # of lookups required.

Since 2005, from the old MAILSIG list to this DKIM list, the numerous 
SSP discussions, threads, debates and thorough analysis by many people, 
 the  major areas of disagreement or contention can best be summarized 
or to included the above items.
I believe that the mailing list usage is still up in the air, but it 
also falls as a sub-set of 3rd party issues.  The key issue with the 
mailing list question is by far the mail integrity issues is no doubt 
introduces.
But overall, since SSP-01, there has always been a source of contention 
on the 3rd party usage.  I believe I called this "Managed vs Unmanaged 
3rd party usage:
     Managed basically restricts or controls who is allowed
     to sign on behalf of the originating domain holder.

     Unmanaged allowed for open ended 3rd party signing.
     I believe John Levine was an advocate of this by elegantly
     pointing out asking what is the difference as long as
     the 3rd party signature is valid.

DKIM allows for a valid DKIM message if at least one signature is valid.

If there was one vital agreement with all parties is this:

     The valid 1st party signature provides a message transaction
     with a high degree of confidence for its validity.

That doesn't not say it is good or bad guy. But it is protocol 
consistent with little need to do anything else in addressing its 
authenticity.  The A/R to determine the GOOD/BAD question is a different 
layer and out of scope consideration.
So the 3rd party usage issue was one of the complex areas that in theory 
came down to offering some form of "list" concept where a verifier can 
use to get domain authorization for the 3rd party usage.
The question was then how would that be done.

There were many discovery process and hotly contested ideas proposed 
form simple list ideas in the SSP records to DNS recursive sub-domain 
lookup ideas.
And finally, in all cases, the overhead concern with # of DNS lookup 
required was also part of the issue in addressing the discovery process. 
 In addition, there was the debate of when it should be done.
All these were address and my review, I personally think SSP allows for 
DKIM protocol consistency checking.
It still fits total picture with any additional A/R implementation layer 
because SSP doesn't address that part of the mail dissemination process.
In the model I see, it can be illustrated as so:

   +-----------+
   |  PAYLOAD  |
   +-----------+
        |
        v
 +----------------+
 |                |                            +------------+
 | DKIM           |--------------------------->| CONTINUE   |
 | Signature      | UNSIGNED: OPTIONAL         +------------+
 | Authorization  |
 | Protocol       |
 |                |                            +------------+
 |                |--------------------------->|            |
 |                | SIGNED: EXPIRED            |            |
 |                |--------------------------->|            |
 |                | NO MAIL EXPECTED           | FAILURE/   |
 |                |--------------------------->| CLASSIFY   |
 |                | UNSIGNED: REQUIRED         |            |
 |                |--------------------------->|            |
 |                | SIGNED: NOT EXPECTED       |            |
 |                |--------------------------->|            |
 |                | 3P SIGNED: NOT ALLOWED     |            |
 +----------------+                            +------------+
        |
        |
     SIGNED
     MESSAGE
        |
        v                                      +------------+
   +--------------+                            | CONTINUE/  |
   |              |--------------------------->| CLASSIFY   |
   |              |    INVALID SIGNATURE       +------------+
   | DKIM         |
   | SIGNATURE    |
   | VERIFICATION |                            +------------+
   |              |--------------------------->| PASS       |
   |              |    VALID SIGNATURE         +------------+
   +--------------+

   Figure 2: DKIM Signature Authorization Protocol Outline

NOTE: THE DIAGRAM IS NOT IMPLYING HOW SSP-01 IS OUTLINED.  It simply 
illustrates to show the DKIM protocol consistency checking is related to 
a SSP idea.
So SSP is just a mechanism to make sure the DKIM protocol is used 
properly and also not abused with the most obvious exploitations.
As was mentioned, the SSP model is for compliant systems - both good or 
bad people. So none of this doesn't eliminate any additional layers for 
actually determining if the message should be accepted or rejected.
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



Steve Atkins wrote:
> On Dec 7, 2007, at 11:45 AM, Hector Santos wrote:
>
> > Steve Atkins wrote:
> > > On Dec 7, 2007, at 10:52 AM, Michael Thomas wrote:
> > > >   It sure isn't obvious to me, and I'm afraid that I'm at the end
> > > >   of the road here as I can't figure out what set of axioms that either
> > > >   you or Dave are operating from for that not be true. From the looks
> > > >   of it, that set of axioms leads to "SSP == bad", so I again wonder
> > > >   why you're wasting your time, unless it is to prevent SSP from being
> > > >   published.
> > > I like DKIM.
> > > Publishing a bad (harmful or overly complex or with no actual benefit
> > > or...) protocol tied closely to DKIM would be bad for DKIM
> > > deployment.
> (There's not much SSP content here. Skip to the final section, or the 
> next message, if you like.)
> > Steve,
> >
> > Are you comfortable with a DKIM only world, if not, what should be 
> > augmented with it to secure some basic exploitations?
> A DKIM-only world would be pretty useless. DKIM is mostly a base on 
> which to build other things.
> > Or
> >
> > Are you comfortable with a DKIM only world with verifiers only 
> > treating valid signatures "more special" than the rest, including a 
> > verifier seeing a domain with all three types of messages coming in, 
> > treating these less special?
> >     NO signature
> >     Valid Signature
> >     Invalid Signature
> >
> > Which ones are more important?
> Well, as an aside, two of those categories aren't valid. There's only 
> "Valid DKIM signature" and "No valid DKIM signature".
> Neither is "more important", they're two types of email that will 
> probably be processed differently by the receiver.
> DKIM-signed mail will likely be cross-referenced with third-party data 
> sources, and moved to the red carpet if it's found to be on them. If 
> not, the longevity and history of it's DKIM identity will be queried, 
> and if it's from an author with a history of sending wanted email, it'll 
> be moved to the red carpet. If neither of those, it'll likely be treated 
> the same as unsigned mail.
> Unsigned mail will be treated as it is now - based on the content, and 
> the reputation of other identifiers in the email (e.g. source IP address).
> Some of this is driven by the receivers needs, though things like 
> registration with third-party data providers will likely be driven by a 
> mixture of sender and receiver needs. (And, don't forget, receivers and 
> legitimate senders have pretty much the same goals - keeping the end 
> recipients happy).
> > What I am pointing out is that, forget SSP, forget everything else but 
> > consider only DKIM, why should a verifier go to the trouble and cost 
> > of development to process DKIM messages when its only interested in 
> > the valid ones and ignoring the rest?
> Because a valid DKIM signature identifies the author 100% reliably. That 
> allows the receiver to do a number of things.
> It lets them track the reputation of the author, both via internal 
> reputation tracking and external reputation and certification services - 
> meaning that they can reduce the false positives of their spam filters.
> It allows them to cross reference that author identity with external 
> third party sources of data (which will allow many of the advantages 
> that goodmail has been hawking, including, for instance, a unique, 
> unfakeable badge in the MUA that the mail came from, for example, a 
> financial institution that is accredited by the US FDIC).
> It allows them to run feedback loops, unsubscription methods and 
> suchlike much more reliably and with lower maintenance overhead, both 
> for the sender and the receiver.
> There's a strong incentive for good actors to maintain a consistent DKIM 
> identity, and that allows all of the above, and a bunch of other things. 
> All good, solid operational benefits.
> > How is the domain protected with is new DKIM signer responsibility?
> >
> > He is only responsible for the mail he does signs and not responsible 
> > for his domain mail he intentionally decides not to sign?
> Of course not. He is responsible for all mail he emits.
>
> But he is choosing to tie the signed mail to a persistent identity, 
> which will (if he has a history of good behavior, or is accredited by a 
> third-party) affect positively the way that mail will be handled by the 
> receiver.
> I suspect that only signing a fraction of mail sent will be not unusual 
> for some types of sender, as will signing with different identities for 
> different sorts of mail.
> > My point in all these question is that there has to be some technical 
> > protocol consistency in all this.  Forget SSP, use something else, who 
> > cares!   I have a hard time believing Verifiers are just going to look 
> > for the valid needle in the haystack while ignore all the other 
> > potential thorns.
> I think it'll mostly be driven by two things. Reputation tied to 
> persistent identity and third-party accreditation. They're easy to 
> implement (based on current technology, just taking advantage of a much 
> better persistent identity from DKIM), and very effective.
> > Of course, we have a problem with mail integrity mishaps.
> >
> > But it doesn't really make sense for verifiers to just accept or treat 
> > more special the valid signature and leave them in limbo with the same 
> > domains being exploited with fake signatures or just DKIM ignorant 
> > legacy bad guys spoofing with non-signed messages.
> > So in one respect, I really don't care what technology XYZ is, we need 
> > something to help protect against DKIM fallacies.
> That technology is probably a mixture of reputation and third-party 
> accreditation.
> > In the other respect, SSP is as good as it gets, in my opinion, as a 
> > open public protocol which interfaces quite well with the possible 
> > DKIM signer results.
> I'd disagree on the "as good as it gets" in implementation terms, but 
> that's a minor issue that can be ignored. Other than that, yes, it's 
> pretty similar to any conceivable protocol based on self-accreditation.
> Lets consider "phishing", which is about the only threat there's much 
> agreement that SSP may be used for.
> If you exclude reputation and accreditation from the setup, and rely 
> *solely* on DKIM and SSP then there is absolutely no difference between 
> mail from sales(_at_)ebay(_dot_)com and sales@ bq--aq276yx7mh7xs.com[1]
> They're both DKIM signed. They both have valid SSP records - in fact the 
> bq--aq276yx7mh7xs.com SSP records may be stricter than the ebay.com 
> ones, as they don't care if some fraction of their mail is discarded.
> So, what do you do now? SSP can only protect an exact sequence of bytes 
> in one header, the associated domain. It cannot protect a brand. It 
> cannot protect the sender as rendered to the recipient in an MUA. It 
> doesn't even try to protect any use of the brand in the body of a message.
> There's a longer discussion as to why "stopping some phishes is not only 
> pointless, but may be actively harmful", but the bottom line is that the 
> only thing SSP can protect is a particular byte sequence.
> Protecting against use of a particular byte sequence is unlikely to 
> provide any real benefit to the sender or recipient unless it is 
> cross-referenced with a list of "legitimate senders" of some sort. And 
> that has been rejected by those considering SSP as useful in it's 
> current form (partly because once you actually have a third-party list 
> of that sort you don't need the self-accreditation of SSP, just the 
> authentication of dkim).
> Hence, again, my question as to what threat SSP is intended to protect 
> against?
> (That's actually a different question to "what can SSP be used for" and, 
> when it comes to making SSP useful, a more useful question to answer.)
> Cheers,
>   Steve
>
>
> [1] For bq--aq276yx7mh7xs.com read "any domain name that'll be rendered 
> similarly to ebay.com in the recipients MUA". or "something semantically 
> similar to ebay.com" or "anything that a recipient might, with no 
> additional data, believe to be a legitimate eBay domain".
> _______________________________________________
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html

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