[ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

[Scott Kitterman]

Douglas Otis wrote:
> 
> On Aug 24, 2005, at 11:14 AM, Scott Kitterman wrote:
> 
>>
>> What you are asking is what won't SSP accomplish.  It's difficult  to 
>> answer those questions before the design work is done.  So lets  quick 
>> arguing about if it should be done.  Get it done and see what  it buys 
>> us.
> 
> 
> Before setting out on change, establish realistic expectations.   
> Currently your conversations should be related to that goal.  What  will 
> domain-wide assertions accomplish?  What threats will this  address?  
> There are a few areas where domain-wide assertions relating  to use of a 
> protocol could be beneficial, such as when detecting  unauthorized 
> servers.  Beyond the immediate domain and server, things  are rather murky.
> 
BTW, I find it an interesting perpective that I am arguing in favor of 
doing DKIM as presented by it's authors and you are not and yet you 
attempt to justify placing the burden of imposing change on me.

> Spend some effort explaining what you envision.
> 
> Provide realistic assessments of what it can accomplish with respect  to 
> current problems.
> 
> Play devil's advocate with what new risks could be created.
> 
> When you say get 'it' done.  I can only guess what you mean.  Hardly  a 
> basis for a charter. : )
> 
It meaning the design of SSP.

What I think we can accomplish is an anti-forgery linkage between what 
is signed and what is visible to the user (the domain part of the 
address, not the local-part and not the pretty name) that will enable 
automatic, deterministic rejection of some forgeries that cannot be 
reliably rejected today.

I expect this to enable domain owners to better protect (to a degree) 
their domains from forgery, phishing, and joe-jobs.

To give an example, if I receive an e-mail from a domain such as e-bay 
(i.e. 2822-From: service at ebay.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.

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

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

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

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

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.

I'm really getting tired of trying to answer your handwaving about why 
this is a bad idea.  Just as a comparison between your gloom and doom 
about the administrative burdens associated with SSP, I think that SSP 
could be far simpler to deploy and maintain than SPF records and yet 
that far more complex technology is one that hundreds of thousands of 
domain owners have found worth the trouble.

Scott Kitterman