Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Apr 2011 18:33:11 -0700

Although DKIM is reviewed within IETF's security area, input validation 
by DKIM remains dangerously neglected.  DKIM's Introduction indicates it 
can be implemented independent of clients.  As such, few assumptions are 
safe in how users become aware of DKIM's intended protections or 
acceptance policies.

The Security Considerations Section 9.14. Attacks Involving Addition of 
Header Fields states:
,---
To resist this specific attack the signed header field list can
include an additional reference for each field that was present at
signing.  For example, a proper message with one From: field could be
signed using "h=From:From:..."  Due to the way header fields are
canonicalized for input to the hash function, the extra field
references will prevent instances of the cited fields from being
added after signing, as doing so would render the signature invalid.
'---

Double listing in the "h=" tag can not fully mitigate risks related to 
appended header fields when messages are signed by a different domain 
than the domain found in the appended From header field.  Users may 
depend upon their employer's or their provider's policies using methods 
similar to those used with ADSP which requires Author Domain 
Signatures.  Whether policies result from a domain publishing ADSP 
records or through private arrangements, these policies may still be 
circumvented with appended header fields.

For example:

From: [email-masked] //bogus header appended to a replayed message
From: [email-masked]
dkim-signature: d=toobigtoblock.com... //valid signature likely accepted
subject: Your account may have been compromised.
More information regarding this problem is available at:
http://example.com/malware.exe

This message will appear properly signed by "toobigtoblock.com" when 
policy adopting DKIM header field conventions are based upon the first 
signed From header field containing: "[email-masked]" and not 
"[email-masked]".  In this case "toobigtoblock.com" may not 
care about appended From header fields and thereby expose big-trader.com 
to being spoofed.

Users may see what appears to be properly signed messages that appear to 
be from big-trader.com and might even be sorted into the same folder as 
messages actually signed by big-trader.com.  Goals stated in DKIM's 
Introduction are only met when few assumptions are made about how users 
become aware of DKIM results.

To prevent appended header fields from being trivially deceptive 
regardless which domain signed the message, modify section 4.5. "The 
DKIM-Signature Header Field" below the paragraph defining the "h=" tag 
by adding:
,---
Always treat the "h=" tag of "from" as having been listed twice.
'---

This change removes reliance on third-party signing domains to also 
provide "h=" lists protecting against deceptive appended From header 
fields.  The From header is the only field that must be signed and only 
one is valid per RFC5322.

-Doug

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 21:18:22 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, April 25, 2011 6:33 PM
> To: [email-masked]; Barry Leiba; Pete Resnick
> Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving
> Additional Header Fields
> 
> than the domain found in the appended From header field.

DKIM doesn't create any binding between the RFC5322.From domain and the "d=" value as you're doing.  What you're talking about here falls into the realm of ADSP or other policy-like assertions, not DKIM itself which is the topic of this draft.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 21:29:35 -0700

On 4/25/2011 9:18 PM, Murray S. Kucherawy wrote:
>> appended header fields when messages are signed by a different domain than
>> the domain found in the appended From header field.
>
> DKIM doesn't create any binding between the RFC5322.From domain and the "d="
> value as you're doing.  What you're talking about here falls into the realm
> of ADSP or other policy-like assertions, not DKIM itself which is the topic
> of this draft.

Perhaps I am wrong, but I believe that this point has been made and re-made
enough times to warrant not making it again.

If someone participating in this working group continues to make that error,
they are unlikely to change.  And the mailing list archive has more than enough 
evidence of clarifying this point; more is not needed.

d/

-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Apr 2011 10:48:41 -0700

> DKIM doesn't create any binding between the RFC5322.From domain and the "d=" value as you're doing.  What you're talking about here falls into the realm of ADSP or other policy-like assertions, not…
Agreed.  The "d=" domain within the DKIM-Signature header field and the 
 From header field may be bound by acceptance policies perhaps due to 
ADSP publications or private arrangements.  It is the From header, not 
the DKIM-Signature header field, most likely seen and sorted by 
recipients, although acceptance may have been based upon DKIM-Signature 
domains.

Security Consideration section 9.14 will not protect phished domains 
where recipients may depend upon policy constraints that bind From and 
the DKIM-Signature field domains.  Unfortunately, despite the protective 
policies and double listings recommended in section 9.14, phished 
domains will still find their From header fields accepted and spoofed 
when signed by otherwise uninvolved "too big to block" domains.

The lack of protection is due to the _base_ DKIM specification omitting 
checks necessary to prevent inadvertent endorsement of replayed messages 
carrying bogus pre-pended From header fields added to a message 
previously originated and signed by an otherwise uninvolved domain that 
may not have a problem with phishing.

Do you see any problem with the suggested remedy?  Section 9.14 still 
supports prior versions of DKIM verifiers although the double listing 
strategy would offer limited protection that appears to assume 
DKIM-Signature domains are somehow visible.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Apr 2011 14:20:19 -0400

I will repeat that this issue was discussed at length, and
working-group rough consensus was reached.  None of the recent
discussion brings up any new points that merit re-opening it, nor is
there sufficient support for re-opening it to cause me to think that
we need to reconsider the consensus.

Therefore, discussion of the multiple-header-field issue is closed;
please do not bring it up again.

Exception: I am aware that Charles and Doug want the issue re-opened.
Anyone else who wants to see it re-opened and discussed again may post
a message to this thread that says "Consensus needs to be
re-evaluated."  I will reconsider this if there's a demonstration of
real support for me to do so.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Apr 2011 11:27:50 -0700

On 4/25/11 9:29 PM, Dave CROCKER wrote:
> >> Double listing in the "h=" tag can not fully mitigate risks
> >> related to appended header fields when messages are signed by a
> >> different domain than the domain found in the appended From
> >> header field.
> >
> > DKIM doesn't create any binding between the RFC5322.From domain and
> > the "d=" value as you're doing. What you're talking about here
> > falls into the realm of ADSP or other policy-like assertions, not
> > DKIM itself which is the topic of this draft.
>
>  Perhaps I am wrong, but I believe that this point has been made and
>  re-made enough times to warrant not making it again.
>
>  If someone participating in this working group continues to make that
>  error, they are unlikely to change. And the mailing list archive has
>  more than enough evidence of clarifying this point; more is not
>  needed.
Dave,

Forgive me, but IMHO you are wrong.  The issue is _not_ about whether 
the From and the DKIM-Signature header fields have been bound by the 
application of policies specified elsewhere and not within the base 
specification.

With the multiple From header field defect being ignored in the base 
specification, malefactors are able to leverage the omitted check to 
obtain unintended acceptance which may injure uninvolved third-party 
domains and their recipients.  Even domains that may make extraordinary 
efforts at establishing restrictive acceptance policies.

Before DKIM is able to offer a trust basis for acceptance, it is 
important that DKIM ensures what has been signed and trusted is not 
easily confused by trivial acts of pre-pending deceptive From header 
fields.  When larger domains fail to include the double listing in the 
"h=" tag because size alone ensures acceptance, all other domains are 
put at risk.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 27 Apr 2011 00:51:16 +0200

> real support for me to do so.

Consensus needs to be re-evaluated. Two reasons:

   1. as Doug pointed out: the basis DKIM spec needs to be such, that
      any technologies, that will use DKIM core as its basis (ADSP, ATP,
      reputation, authorization to use a mailing list, etc. etc.) must
      be able to rely on a single outcome of the DKIM verification
      process. As par. 5.1 of 4871bis provides a wealth of examples why
      there can be multiple signatures and par. 5.2 provides the
      recommendation (SHOULD) to '...continue to check signatures until
      a signature successfully verifies to the satisfaction of the
      verifier', it seems to me that bad guys adding a set of header
      fields (like From, Subject) can create a 2nd, 3rd, ..., n-th)
      signature (using their own d=) that may verify successfully 'to
      the satisfaction of the verifier'. Furthermore, as par. 7.2 does
      not define the exact information that is to be communicated to
      other parts of the mail system, it is possible that a 'verified
      successfully' outcome is communicated to downstream mail agents,
      without information about d=. And with 'downstream agents' I do
      not mean only UA's, I mean ANY agent consuming the verification
      result as determined by the verifier.
   2. in addition to the above, I fail to see why
      - on one hand 4871bis goes to great lengths regarding security
      related aspects ('sha-256 is strongly encouraged' and 'signers
      MUST use RSA keys of at least 1024 bits'),
      - while on the other hand not enforcing the 'multiple header'
      check. In my view 4871bis must either assign a PERMFAIL
      verification outcome for messages that fit the description of par.
      9.14 and 9.15, or it should use a MUST for the h=From:From:To:To:
      construct.

Granted, under normal circumstances I hate layering violations, but in 
my view this duplicate header check is essential for DKIM to be useful. 
Compare it to the Jericho security model: in these days of 
virtualization, DHCP etc. etc., a company can no longer simply rely on 
the IP firewall rules, each system has to become a self containing 
security ecosystem, which can easily be moved from one location to 
another. Likewise DKIM can not simply rely on MTAs/UAs properly 
implementing RFC5322, for a few essential things in RFC5322 DKIM has to 
doublecheck.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 20:03:47 -0400

Dave,

Everyone accepts (maybe some reluctantly and with high DKIM concern), 
the *policy semantics* separation between the AUID and SDID from 
RFC4871bis.

My exception is the incorrect extended assertions there is no DKIM 
created binding association between the 5322.From and the signature 
signed by SDID:

     DKIM doesn't create any binding between the RFC5322.From domain
     and the "d=" value

That is simply not correct. Its not like the signer (d=) has a choice 
in the matter.

For some reason (perhaps out of DKIM-BASE scope), the SDID, as the 
responsible signer, must bind 5322.From to the signature. Perhaps it 
will help to describe the DKIM mandate to bind the 5322.From to the 
signature signed by the SDID?

   - Is it for some higher security reason?
   - Is it because it is RFC5322 requirement also?
   - Is it because its something the MUA will see?
   - Is it to prepare some future Identity Assessor module?

IMV, all this can be solved by being straight with the DKIM Mail 
Integration intentions, not with continuous *denial* there is an 
unique 5322.From binding association with the signature. It may be 
"out of scope" reasons, but a binding association nonetheless.

-- 
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Apr 2011 19:18:24 +0100

> circumvented with appended header fields.

I have proposed some alternative texts for this in a separate thread, and  
Murry seems happy to accept them, so that is a slight degree of progress.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Apr 2011 19:23:31 +0100

On Tue, 26 Apr 2011 05:29:35 +0100, Dave CROCKER <[email-masked]> wrote:

> re-made

Not so. DKIM specifically requires that the From header be included in the  
signature. Hence end users (and that included verifiers) are entitled to  
assume that if there is a valid signature, then "the" From header that  
they see before them was signed. So there does already exist a binding  
quite independently of ADSP or reputation suystems, or any other "addons".

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Apr 2011 18:28:49 -0400

> real support for me to do so.

I now add Rolf to the list, and it occurs to me that in order to
reconsider consensus we need a clearly stated alternative -- one
alternative, not, perhaps, three that differ.  I, therefore, ask Doug,
Charles, and Rolf to get together (by email, phone, Skype, whatever)
and come up with *one* proposal that you can all stand behind and say
"This works for me."

When you have that, one of you please post the proposal to this
thread, and we can evaluate it and see where we are, and whether
others can agree with what you come up with.

This weekend is far too soon to require this, but it will Really Help
Me if you can do it by this weekend, so I can have it when I'll see
Sean in person and have a chance to talk it over with him.

In any case, I'd like to set an absolute deadline of 6 May for it.  It
will take me at least that long to collect things after working group
last call officially ends -- I will be in Amsterdam early next week.

Please let me know off-list if you have any questions or problems with
this [you may, of course, post on list if you prefer].

Barry, as chair

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 28 Apr 2011 16:37:08 +0200

> this [you may, of course, post on list if you prefer].

My major concern will have been addressed as soon as we can get 
consensus on a clear, unambiguous and complete 'output', in section 7.2. 
If the consumer agent gets the right information, it's up to that agent 
to use it for what it wants to do with it (reputation, make phishing 
visible etc. etc.). So for the moment I would like to try to focus on 
the 'Output' discussion, not on the validation of Input.

/rolf