[ietf-dkim] Collection of use cases for SSP requirements

[Douglas Otis]

On Nov 9, 2006, at 7:40 AM, Dave Crocker wrote:
> Charles Lindsey wrote:
>>
>> Well at least it is a start to force the phishers into using look- 
>> alikes.
>
> As soon as banks start signing their messages and there are  
> credible whitelists for their domain names, doesn't this end the  
> ability for phishers to use those domain names in the rfc2822.From  
> field?

Unfortunately, a DKIM signing-domain white-list based upon trust or  
reputation is prone to abuse.  Someone with access to a domain can  
send themselves messages that can be replayed from anywhere.  For the  
MTA, without some mechanism to identify when it is safe to apply a  
white-list, DKIM would not be validated to conserve resources.  The  
MUA may wish to validate DKIM signatures to confirm the recognized  
identity before annotation is applied.


> Therefore, how does SSP have any effect?
>
> That is, if the message is signed and the whitelist says the signer  
> is a Good Actor, the the message is handled with a favorable eye.   
> If the message is not signed, it is handled with a suspicious eye.
>
> Exactly where does SSP fit into the protection scheme?

When attempting to defeat spoofing, message annotation is required.   
The annotation should be based upon:

A) Matching with trusted email-address assured valid via signature  
semantics or policy assertions.

B) Matching email-address trusted domain where policy asserts the  
specific email-address as trustworthy.

The annotation scheme defined in DOSP provides a formidable defense  
against phishing or other types of spoofing.

> What use case does it cover?

White-listing protection:

When a receiver wishes to white-list big-isp.com because a few of  
their users run afoul of their block-lists.  Once it becomes  
understood by the bad actors able to gain access to big-isp.com, then  
any white-listing hoping to bypass block-lists will prove  
disastrous.  DOSP offers a means to associate the SMTP client with  
the signing domain.  This association allows white-listing to be  
safely applied based upon either trust or reputation.

DSN assurance:

The same association strategy can assure the 2821.MailFrom address  
without the problems related to address-path registration.

Autonomous designation of providers:

The same association strategy eliminates an exchange private keys,  
delegation of DNS zones, or publishing CNAMEs at specific selector  
leafs.  This association strategy also allows autonomous management  
of a customer's relationship with their providers.  (Good for the  
customer and good for the provider as they will receive abuse feedback.)


> Exactly which SSP flag/mechanisms is it that provide this  
> additional benefit?

<hash:signing-domain>.<email-address-domain> RR  "a=signing-domain f=A

>>> Many of them use their own domains, for which they could  
>>> trivially publish SSP data.
>>
>> Which is where we need sites on which "reputations" can be queried.
>
> Exactly.  In which case, what is the need for SSP?

When there is a desire to secure private keys and still having  
messages receive an authorization signed by the providers domain.

> And, since I happen to think that SSP *can* provide some utility,  
> here's the case that makes sense to me:
>
> For domain names that are in the whitelist, an SSP flag that says  
> "I sign everything" gives me the ability to handle unsigned  
> messages using that domain name in the rfc2822.From (or  
> rfc2822.sender?) field with *extreme* prejudice.

So what?  In reality this blocking effort affords little protection.   
When the domain also wishes to use mailing lists, extreme prejudice  
will significantly reduce the integrity of their email.  Different  
policies within sub-domains only increases the likely success of  
phishing attempts.

> This seems useful to me.
>
> Not earth-shakingly great, but at least useful.

Not really.  It establishes bad practices and will create problems  
for virtually no benefit.  DKIM can not be applied with respect to  
white-listing except perhaps in a select few cases such as bulk  
senders.  Attempting qualify email-address originating domains only  
when matching with the signing domain creates additional problems.   
These problems can be resolved without requiring any additional DNS  
transaction as described in DOSP.

-Doug