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

[Douglas Otis]

On Nov 8, 2006, at 7:55 AM, Steve Atkins wrote:
> On Nov 8, 2006, at 4:24 AM, Charles Lindsey wrote:
>> On Wed, 08 Nov 2006 04:46:08 -0000, wayne <wayne at schlitt.net> wrote:
>>
>> I think some site like a Bank, that is heavily phished, might go  
>> so far as to declare "I sign all mail. Please delete/reject/drop/ 
>> whatever (perhaps even silently) all messages that fail to verify".
>>
>> That site would have to be pretty confident that the genuine mail  
>> it sent out was 100% clean, but it might well decide that it was a  
>> lesser risk to have some genuine messages dropped than to let  
>> phishes go through.
>>
>> BTW, are there any plams to have keywords for some of the various  
>> policies that might be declared, so that verifiers (or rather  
>> their policy modules) could recognize them and adjust their policy  
>> accordingly)?
>
> I do have to point out that SSP will not affect phish emails  
> noticeably, after a very short transition period.

Validity and trustworthy assertions allow message annotation based  
upon either out-of-band trusted email-addresses or trusted domains.   
This annotation approach provides formidable protection against look- 
alike phishing.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

> So if a bank were to do this it would mean 1) phishing mails won't  
> be affected and 2) legitimate mail from the bank is likely to be  
> affected.
>
> So... what's the _real_ use case, again?

The DOSP proposal solves several use cases:

DSN:
Validation of disparate rfc2821.MailFrom is accomplished within a  
single small DNS transaction.  This association is not prone to the  
many problems associated with address path registration.  Address  
path registration breaks with forwarding.  The size of a data-set  
needed for address path registration also leads to serious DDoS  
concerns.

Protect DKIM white-listing:
Validation of disparate SMTP clients is accomplished within a single  
small DNS transaction.  The association can utilize either address- 
literals or host names and assumes the EHLO has been validated prior  
to accepting the message.

Simplify provider designation:
A designation scheme can be accomplished within a single  
transaction.  This eliminates the need to exchange private keys,  
delegate DNS zones, or establish CNAMEs where the provider creates  
your private keys and only shares the public version.  These  
arrangements will be difficult to scale increasing cost and will  
likely lead to higher rates of invalid signatures due to  
configuration errors.  These arrangements will impede consumer's  
choice of providers.  A provider using their customers keys and  
domains also means forgoing valuable abuse feedback.

Anti-phishing:
Support annotation constructs that utilize the recipient's address- 
book or a list of trusted domain.


The different DNS checks (and even DKIM validation) should only be  
done when there is a direct benefit.  It remains doubtful that there  
is benefit hunting for policy that indicates a message should be  
signed.  The annotation strategy prevents such messages from spoofing  
recipients.

-Doug