Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does no

On Aug 24, 2005, at 12:10 PM, Scott Kitterman wrote:

> To give an example, if I receive an e-mail from a domain such as e- 
> bay (i.e. 2822-From: service(_at_)ebay(_dot_)com), Ebay has published a  
> restrictive SSP that says messages are all signed, but please don't  
> accept 3rd party signing, I want to be able reject the message at  
> SMTP time if it is either unsigned, 3rd party signed, or has a  
> broken signature.

For those using a very popular MUA, this type of mailbox routing  
protection is of little worth.  In addition, should a miscreant claim  
service(_at_)example(_dot_)com, qc(_at_)ebay(_dot_)com, the From is no longer assessed.   
Instead a likely an unseen Sender header may be used instead.  There  
are several other exploits SSP restrictions allow, better addressed  
by the opaque-identifiers and an opportunistic identification approach.
3rd party signing restrictions will likely warrant a need for  
exceptions lists.  To be sure to find the domain-wide assertion for a  
3rd party From (with respect to the signer), walking the DNS label  
tree in an upward direction is currently required.  This approach  
would require lookups for domain-wide assertions and exception lists  
for every message.  Is there an easier way that does not require  
domain-wide assertions?  There is.

> On the other end of the spectrum, I want to reject messages during  
> SMTP that the SSP says never send mail.

There are any number of methods that can be used to accomplish this  
worthy goal.

> There are gradations in between.
>
> I expect that this type of capability will force forgers, phishers,  
> and joe-jobbers to move to other attacks less likely to be successful.

Forgers, phishers and job-jobbers will thank you profusely for  
permitting them an easier method of establishing the (false)  
confidence of their victim.
How will DKIM stop joe-jobbers? (Those who spoof the bounce-address  
as a ploy to evade IP based reputation checks when their messages are  
mistakenly returned to the wrong party.)  I did not expect DKIM to be  
checking the bounce-address, nor will the DSN likely retain a valid  
signature.  It would seem that DKIM again will only help with this  
exploit as well.  Will this concern only generate a new set of  
authorization tables in these SSP domains-wide assertions?  Will SSP  
become the veritable "stone soup" of DNS, as yet another ingredient  
is added.  SSP, the Stone Soup Project?

> In other words, I expect them to shift from forms that are the most  
> likely to be successful social engineering experiments to riskier,  
> less sucessful forms.

How does DKIM prevent social engineering attacks?


> The risk is that there could be a false sense of security since the  
> protections I envision as being feasible have substantial limitations.

On that point I agree.


> This is all conceptually in the DKIM-SSP draft, so I don't know why  
> you feel like I need to explain it.

At least I understand now what it is you are claiming.  I do not  
agree that SSP, with respect to mailbox-address restrictions, provide  
significant advantages, but instead offers substantial overhead and  
risk.  Particularly the risks created by professions the mailbox- 
address is being directly protected by DKIM.  There are other issues  
that need to be addressed, such as replay and correlation.  When  
these other issues are addressed, it becomes more apparent the  
limited value of SSP.  Perhaps SSP could offer default binding  
recommendations, or assertions of DKIM compliance, but that would be  
assuming opportunistic identifications would be the norm, where none  
of this information would be typically checked.

> As I said before, let's just agree that there is work yet to be  
> done on SSP and quite arguing about if it should be done.

We are back to using the term 'it' again as if 'it' has special  
meaning.  You have made wild claims without providing any  
substantiations.  Please don't think of SSP as justification for yet  
another 'kitchen sink' approach where everything is stirred together  
until someone proclaims "RFC-Soup."  Now is the time to be  
realistic.  This should not be about selling a general concept of mom  
and apple pie.

-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org