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

From: "J.D. Falk" <[email-masked]>
Date: Tue, 21 Nov 2006 15:02:27 -0800

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.

Should that be in SSP?  Should it be in something else?  Should I 
encourage all of the banks to use a non-standardized external mechanism 
while y'all argue?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Product Platform Group
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Nov 2006 23:16:09 +0000

> encourage all of the banks to use a non-standardized external mechanism 

When you read the ssp-reqs, did you find what you want there? If not,
then why not write the relevant paragraphs and see if people like them.
That's how things get done, as opposed to argued about.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Nov 2006 15:27:15 -0800

> don't care about anything else the sender may want to assert.

Your premise is that you will find it useful to know that First Amalgamated 
purports to sign everything.  Let's ignore what you will do with that 
information; it's your business not ours (and possibly not even First 
Amalgamated's.)

The next question is whether there is a rough consensus of folks, here, who 
agree with the desire to know this information.

I will ask for one clarification:  What do you mean "I really don't care about 
anything else the sender may want to assert"?  Certainly only the sender -- if, 
by sender, you mean FirstAm -- is the only one that can claim that they sign 
everything.

> encourage all of the banks to use a non-standardized external mechanism 

Discussion, here, has been about having an SSP flag that lets a potential signer 
say "I sign all my mail and my signature matches the rfc2822.From (or maybe 
rfc2822.Sender) field domain name."

Would this satisfy the requirement you are offering?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 21 Nov 2006 18:31:28 -0500

J.D. Falk wrote:

> Should that be in SSP?  

Yes.  It is a simple DNS query.

> Should it be in something else?  

No, not if its not a standard.

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

No, not in my view, because exploiters will use that special YAHOO/BANK 
non-standard process against other systems in yet another attempt to 
mask the message as legitimate.  In fact, in my technical opinion, you 
might put the bank at risk by encouraging a non-standardized method.

Hector Santos/CTO
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Nov 2006 15:45:45 -0800

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.

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Nov 2006 15:56:23 -0800

>That's how things get done, as opposed to argued about.

It is pretty clear this is covered in Section 6.3, #5.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html