>-----Original Message----- >From: John Levine [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 23, 2008 4:06 PM >To: [email protected] >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 [EMAIL PROTECTED]). 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
