Subject: Re: [ietf-dkim] Pete's review of 4871bis

From: Douglas Otis <[email-masked]>
Date: Fri, 01 Jul 2011 14:43:09 -0700

On 6/29/11 11:49 AM, Pete Resnick wrote:
> On 6/29/11 11:20 AM, Charles Lindsey wrote:
>> I agree that 8.14 is poorly written (and it was even worse a while back).
>> However, there most certainly IS an attack here, which is NOT the same as
>> the related attack discussed in 8.15, and cannot be prevented by putting
>> extra entries in the 'h=' tag. Unfortunately, many WG members have failed
>> to understand the difference between the two. Here is the attack,
>> described in plain terms:
>>
>>
>> A phisher obtains a throwaway domain and creates a public/private key pair
>> for
>> it. He then sends messages of the following form:
>>
>> ------------
>>
>> To: [email-masked]
>> From: eBay<[email-masked]>
>> Date: Tue, 17 May 2011 13:21:06 +0100
>> Subject: Some plausible Ebay subject
>> <Lots of other normal headers>
>> From: [email-masked]
>> DKIM-Signature: v=1; a=rsa-sha256; d=mythrowayawdomain.example;
>>          h=from:to:subject:date; ....... b=<valid signature>
>>
>> Body of message of typical Phish style.
>>
>> -------------
>>
>> A compliant DKIM verifier will report that as a validly signed message.
> The second From field is absolutely irrelevant in the example. The
> phisher could simply leave out the From field with their address in it
> and sign the ebay From field.
>
> And that's not an attack. The signer signed the message and the
> signature verifies. *DKIM* has done its job successfully and has not
> been attacked. DKIM communicates from the signer to the verifier. The
> signer *can't* attack itself. You *might* characterize this as an attack
> against 5322 (in that From addresses are not bound in any secure way to
> the actual author), but DKIM does not even attempt to address that
> attack, so it's not an attack against DKIM. You go on to say something
> that is an attack, but again you get the analysis wrong:
>
>> The
>> Ebay signature is irrelevant for the signing process (so even if Ebay has
>> declared a "Discardable" ADSP policy it will not be invoked).
> Now *that's* the attack. But it's NOT AN ATTACK ON DKIM! It's an attack
> on ADSP. If ADSP sees the above message and doesn't discard it, then
> ADSP has done the wrong thing. If ADSP has a bug where it thinks it
> ought not discard the above message (with the appropriate policy), then
> that should be fixed. It should certainly be called out in the security
> considerations of ADSP. But it's NOT a security consideration for DKIM.
This is a poor example of a potential problem.  The problem may occur 
whenever email acceptance is predicated upon the signing domain.

When this domain is of sufficient volume where this domain constrains 
the From to being within the same domain or verified by a ping-back, on 
that basis their messages should be safe to accept.  However when 
pre-pended From header fields are not precluded from producing valid 
signatures, (a silent condition) acceptance on the basis of a high 
volume signature would not be safe, whether or not ADSP is applied.
>> Normal
>> readers
>> using current MUAs will see just the From: Ebay header and, believing that
>> their ISP has done some magical cryptographic checks to prevent bogus Ebay
>> messages from getting through, will be reassured.
> Again, the second From is not required for that to happen. If MUAs
> believe that some magical crypto thing happens to a message with
> "d=badguy.example" and "From: ebay" (with no other From's), then they
> get what they paid for.
Agreed.  But then this would not be basing acceptance on the signing domain.
>> The present draft does make some woolly attempts to fix this problem.
>> Section
>> 3.8 says "verifiers SHOULD take reasonable steps to ensure that the
>> messages
>> they are processing are valid according to [RFC5322] ... ". But gives no
>> guidance as to what "reasonable" means (and full RFC5322 compliance
>> checking
>> is notoriously hard). It now refers to to both 8.14 and 8.15, but leaves
>> it to the implelemtor to work out what he needs to do.
> As this conversation has developed (here and off line), I'm getting
> convinced that 3.8 is a red herring. DKIM deals perfectly well with the
> obsolete message format, including multiple From fields. I think the 3.8
> admonition is overblown.
>
>> In my opinion, there needs to be some REQUIRED action in the verifier which
>> will result in a PERMFAIL, and which would then catch all attacks of this
>> nature. But the WG consensus has been against this.
> If the WG is against it, it is correct. This is NOT a PERMFAIL condition
> for DKIM. It is probably a PERMFAIL condition for ADSP, but that's a
> different document.
So much for safe incremental deployment. :^(

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 01 Jul 2011 14:11:46 -0700

On 6/30/11 9:53 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
>> Sent: Thursday, June 30, 2011 7:05 AM
>> To: DKIM
>> Subject: Re: [ietf-dkim] Pete's review of 4871bis
>>
>> The problem is that an apparently valid signature (albeit atching the
>> wrong From) is likely to give a false impression of validity somewhere
>> along the line unless modules down the line are watchig for this case (and
>> for sure MUAs will not be watching for it for a long time, so it is the
>> ISPs/boundary agents that need to do it).
> If the advent of DKIM means that numerous modules implementing other specifications loosely suddenly have to pay a price for doing so, then that's the reality, and I still don't see how that's a problem DKIM needs to fix.  Sure, we need to document the nuances DKIM introduces, but it's still not an attack against DKIM, so this remains the wrong place to deal with it in a normative sense.
>
> If you prefer the loose application of other standards, don't use DKIM (and lose out on its benefits).
Murray,

DKIM is not enforcing RFC5322's format.  Nor is it reasonable to expect 
that SMTP has either.

It is reasonable to expect security related protocols validate input.  
Whether a message gets rejected or dropped is immaterial.  For DKIM's 
output to be usable, it must be clear what was signed without expecting 
subsequent message handlers to adopt bottom-up selection.  Otherwise, 
DKIM can not be safely deployed in an incremental fashion as claimed in 
its introduction.

-Doug