[ietf-dkim] "I sign everything" yes/no

[Douglas Otis]

On Nov 21, 2006, at 3:02 PM, J.D. Falk wrote:

> Imagine, if you will, that I'm a big ISP with lots and lots and  
> lots of consumer type end users who prefer to stay clueless about  
> the intricacies of e-mail.
>
> A message comes in which claims to be from the First Amalgamated  
> Bank of Example.  An entirely separate, unrelated mechanism has  
> already told me that example.com really is the domain name used by  
> the First Amalgamated Bank of Example, and that they're a real bank  
> with tellers and vaults and bulletproof glass and all that fun stuff.
>
> But this message isn't signed (and/or the signature is invalid,  
> which base says is the same thing.)  How do I find out whether or  
> not the First Amalgamated Bank of Example thinks that they sign all  
> of their messages?  That should be a simple, binary operation,  
> right?  I really don't care about anything else the sender may want  
> to assert.

Why should an email provider care whether a banks sign all of their  
messages?

Why should an email-provider care whether first-amalgamated-bank-of- 
example.com or 1st-amalgamated.com is their real domain?

To thwart phishing with millions of possible look-alike and cousin  
domain attacks, the clueless recipient must have a mail-user-agent  
that can determine whether a signed domain is found in their address- 
book.  When the domain is not in their address-book, the signature  
should not be checked as this leaks valuable information to bad  
actors.  Just annotate those messages that are signed and found in  
their address book.  Do that and you can stop worrying.

Walking up label trees in response to each and every possible spoof  
received is not a good or safe choice.  Marking messages as being  
compliant with some self-asserted requirement is not a good or safe  
choice either.  In other words, the last thing an email provider  
should be doing is looking for authorization schemes.

Depending upon an authorization scheme to block phish attempts risk  
of making those messages still accepted look even more official.   
This would represent an extremely poor trade-off.  Don't go looking  
for no stinkin' authorization!

> Should that be in SSP?

No.

> Should it be in something else?

No.

>   Should I encourage all of the banks to use a non-standardized  
> external mechanism while y'all argue?

No.  Develop tools that confirm a signing domain is associated with  
an email-address found within the recipient's address-book.  This  
effort does not require anything more from financial institutions  
beyond simply signing their messages.   This approach also allows  
them to continue to contribute to mailing lists as well.  An  
authorization scheme represents an extremely poor choice that is only  
likely to create excessive traffic and further mislead the clueless.

To better serve those wishing to utilize the Yahoo signature, develop  
a simple association technique that allows autonomous management of  
other domain's relationships with Yahoo without exchanging private  
keys, CNAMEs, or delegating DNS zones.

To better protect the Yahoo signatures being used for white-listing,  
develop a similar technique that associates with SMTP clients.  When  
an association is not found, the signature should not be used for  
white-listing.  This would absolutely prevent the likely replay abuse  
of the Yahoo signature.

To better protect the DSNs, develop a similar technique that  
associates with the MAILFROM with the signing domain.

-Doug