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

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 to 
http://mipassoc.org/dkim/ietf-list-rules.html