ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] the more reliable signature fallacy

2008-01-23 16:00:01


-----Original Message-----
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com] 
Sent: Wednesday, January 23, 2008 4:06 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: MH Michael Hammer (5304)
Subject: Re: [ietf-dkim] the more reliable signature fallacy

From my reading, I would assert that it is logical that the 
check MUST 
be made if there is no valid signature on behalf of the from address. 
To do otherwise invites abuse.

Why?  Nobody I know is saying that any signature gives a 
message a free pass, but if it's signed by someone you have 
reason to trust, why aren't you done?  Could you give us a 
step-by-step example of the abuse you're anticipating?

Assume that the signature is from someone you've known and 
trusted for 20 years, and you've never heard of the From: 
domain before.


Your last point is an artificial construct. Remember, the discussion is
about Sender signing vs From Signing. Is your trusted friend signing as
sender or simply appending their signature? Is this a general case? Is
it even a likely case? In what case would your friend be signing as
sender if the From domain owner has not signed and their SSP says that
they always sign their email?

Moving on to my example, the first step is for us to create a matrix of
use cases along the lines of:


From  |Sender|  Trusted    Neutral Untrusted   No SSP
-----

Trusted

Neutral

Untrusted

No SSP


We can add whatever additional variations we choose but for discussion
purposes a 4x4 matrix is sufficient. In reality it's more complex
because we have to account for whether or not there is a signature at
all for particular cases. I'm only going to discuss two cases...The one
you set up and the one I will set up. I'm going to assert that the one I
set up is more likely to be faced by receivers if "Must check" is
dropped.

The example you set up is an easy but unlikely one as far as I can see.
Your answer would be "Who's your friend?" You would likely accept it
because your friend signed it. My answer would be "Friends don't sign in
weird circumstances if they are truly friends." They might forward the
email. They might sign if there is no SSP for the From domain. I find it
an odd case that someone would be signing as sender if the origin domain
did not and it's SSP says everything is signed. I'll grant you that
there might be some confusion and poor implementation leading to your
example as SSP and DKIM are deployed.

As I pointed out above, I view your example as highly unlikely.

What about the case where SSP for From says everything is signed? If
From isn't signed and Sender is signed, then unless you require an SSP
Check for From you can only rely on Sender. I'm going to guess that you
would respond that Sender would acquire a poor reputation if they signed
for spammy malicious email. Now what if (those evil ne'er-do-wells
really can get creative) the bad guy simply uses a new sender domain for
each email sent (or each 5 or 10, whatever works for them). This
effectively allows abuse of the From domain unless there is a mandatory
check of the From domain. You might respond that the IP address of the
sending machine would acquire a poor reputation...but that isn't DKIM
and is beyond the scope of the discussion (as a solution).

This is the exact problem for PRA in the SIDF implementation. Because
the specification mandates the use of Sender as PRA if Sender is present
and excludes checking From, it invites abuse cases that are perfectly
allowable within the terms of the specification. I'm not looking to bash
the folks that came up with the PRA algorithm. There's been plenty of
nit-picking and arguing over other issues but I haven't seen any
detailed published analysis of this particular issue. I've gone through
and sent all sorts of test emails to various receivers that implement
SIDF. It is a problem in the RFC and not an implementation issue.

There is a real quick simple way to test what I am saying. Construct an
email purporting to be from thatsgross.com (that is, the From field is
something(_at_)thatsgross(_dot_)com). Send it from a machine (using the sender
field) that uses some other domain and publishes a SPF2.0/PRA record for
that domain that authorizes that host to send. The email should (and
will) pass an implementation of SIDF that conforms to the
(experimental)standard. 

The domain thatsgross.com simply has a -all record for both spf1 and
spf2.0. 

The actual records returned are:

thatsgross.com  text = "v=spf2.0/pra -all"
thatsgross.com  text = "v=spf1 -all"

Any mail purporting to be from that domain SHOULD FAIL a check. But SIDF
specifically says that if Sender is present then that is PRA and you
don't check anything else. 

If the decision is that people don't have to check SSP (drop MUST and
insert MAY) for from domain then it is setting up the same sort of
situation that currently exists for PRA. If we want to protect domains
(and the account users that must adhere to the policies of the domains
that provide them accounts) it is imperative to require a check for the
originating domain. 

If all of the From addresses are within a domain then there shouldn't be
a problem. If the From addresses are from multiple domains then my
inclination is to say that all From domain policies (SSP) need to be
considered for making a determination. In reality I'm sure - as others
have pointed out - that there is a practical limit to how many will be
checked. I've dealt with millions of emails and don't see many that have
multiple Froms. I don't remember (off the top of my head) seeing any
with lots of froms. It may be allowed but it doesn't really happen in
practice.

Mike


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html