Subject: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Oct 2010 21:58:29 -0700

8.14 Malformed Inputs

DKIM allows additional header fields to be added to a signed message without breaking the signature.  This tolerance can be abused, e.g. in a replay attack, by adding additional instances of header fields that are displayed to the end user or used as filtering input, such as From or Subject, to an already signed message in a way that doesn't break the signature.

The resulting message violates section 3.6 of [MAIL].  The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it will display the newly added header fields rather than those that are part of the originally signed message alongside some "valid DKIM signature" annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field.

Because of this, DKIM implementers are strongly advised to reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject).  A signing module could return an error rather than generate a signature;  a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates.

Senders concerned that their messages might be particularly vulnerable to this sort of attack and do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further discussion of this mechanism.

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Oct 2010 04:49:44 -0400

I will not pretend to know (nor really care) what it will take to get 
over this documentation dilemma but I will provide my comments here:

Murray S. Kucherawy wrote:
> 8.14 Malformed Inputs
> 
> 
> DKIM allows additional header fields to be added to a 
> signed message without breaking the signature.  

DKIM does not "allow" additional header fields. It just didn't check 
for conditions that were problematic.  If this issue was obvious back 
during the TA work, we would not say this and the checks (exceptions) 
would be incorporated in Section 5.4 today.

A better "friendlier" opening theme sentence is:

    There are known conditions which can alter the originality of a DKIM
    signed message without breaking the existing signature validity.

> This tolerance can be abused, e.g. in a replay attack, by adding 
> additional instances of header fields that are displayed to the end 
> user or used as filtering input, such as From or Subject, to an 
> already signed message in a way that doesn't break the signature.

This is close, but again, there is no "allowance" or a "tolerance" 
because, for the most part, DKIM was essentially "ignorant" of the 
conditions due to lack of vision during the TA.  So I think the text 
following the opening theme could be:

    Since it is possible to maintain the integrity of the signature with
    these known non-compliant RFC5322 message alteration conditions, 
there
    is an increase possibility of abuse and exploitation of MUA 
displaying
    information which were not validated by the signature.  Examples may
    be non-compliant  RFC 5322 messages containing a 2nd 5322.From or 2nd
    Subject headers which were not hash bound to the DKIM signature, 
yet due
    to the nature of MUAs, the wrong header could be displayed to 
end-users.

> The resulting message violates section 3.6 of [MAIL].  

What resulting message? The one DKIM ignorantly neglected to check?  I 
think my text above covers the "blame" and IMO this sentence can be 
pulled.

> The way such input will be handled and displayed by an MUA is 
> unpredictable, but in some cases it will display the newly added 
> header fields rather than those that are part of the originally 
> signed message alongside some "valid DKIM signature" annotation. This 
> might allow an attacker to replay a previously sent, signed message 
> with a different Subject, From or To field.

I think handled and displayed can be seen as two different things or 
levels.

Backend handling can be very predictable, Frontend displayed may not 
be since the MUA can be online or offline.  Online can be predicted, 
offline less predictable but the odds are very high that what is shown 
offline will match what would be shown online for the simple reason 
systems that offer both modes take these offline vs online ergonomical 
issues into account to the best of its ability.
We want the offline experience to match that of the online experience.

We author a variety of MUA software from offline to online.  Overall, 
there are certain messages headers that are expected to occur only 
once and thus including the overhead to parse or check for a 2nd or 
more header may not even be a considerations for some and even if it 
was, it could be viewed as redundant overhead.

So its very predictable most parsers will mostly use the first header 
found and the only thing that is unpredictable is whether these 
special redundant overhead double header conditional checks are 
performed to a wide degree.

I would change this to:

   It is unknown how these non-compliant RFC5322 messages will be 
handled by
   backend MTA receivers and how MUAs will display them.  It is 
conceivable,
   some MTAs will reject these messages while other MTAs may accept it
   but only after it has sanitize the message for user display.  Yet other
   MTAs may be unaware of the multiple headers in these non-compliant
   RFC5322 messages.

   Under unchecked conditions, this can allow an attacker to replay a
   previously sent, signed message with a different Subject, From or To
   field.

> Because of this, DKIM implementers are strongly advised to reject 
> or treat as suspicious any message that has multiple copies of header 
> fields that are disallowed by section 3.6 of [MAIL], particularly 
> those that are typically displayed to end users (From, To, Cc, 
> Subject).  

I am not sure about this. More below.

> A signing module could return an error rather than generate a 
> signature;  a verifying module might return a syntax error code 
> or arrange not to return a positive result even if the signature 
> technically validates.

I am not sure about this because there are variations of solutions and 
I don't think the above covers them all.

I would like to see something more generic that could cover in general 
the different ways DKIM processing may be integrated.

Maybe text like:

    Despite the apparent scope of this requirement, there are
    implementation circumstances in which how DKIM processes
    these non-compliant RFC 5322 messages not be determined until
    it is known how messages are first passed or reach integrated
    DKIM processors.

    With an increase alertness of the possibility for these
    non-conforming RFC5322 yet DKIM compliant messages, receiver
    MTA may begin to perform this filtering at an increase level.
    This form of processing will minimize any implementation
    requirement for DKIM to perform this non-compliant mail check.

    In addition, enhanced MUA operations can address the situation
    as well with attentive awareness of non-compliant message displays.

> Senders concerned that their messages might be particularly vulnerable to 
> this sort of attack and do not wish to rely on receiver filtering of 
> invalid messages can ensure that adding additional header fields will 
> break the DKIM signature by including two copies of the header fields 
> about which they are concerned in the signature (e.g. 
> "h= ... from:from:to:to:subject:subject ...). See Sections 3.5 
> and 5.4 for further discussion of this mechanism.

I would change this to:

    To address current or legacy email implementations that may not
    aware of these non-compliant RFC 5322 double header messages, DKIM
    Signers concerned their signed outbound messages might be
    particularly vulnerable to this form of attack can ensure that
    adding unexpected additional header fields will break the DKIM
    signature by including two copies of the header fields about
    which they are concerned in the signature h= tag e.g. "h= ...
    from:from:to:to: subject:subject...". See Sections 3.5 and 5.4
    for further discussion of this mechanism.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Oct 2010 05:23:07 -0400

For readability, I will propose my 8.14 text change suggestions as a 
whole:

8.14 Non-Compliant RFC5322 Messages

   There are known conditions which can alter the originality of a
   DKIM signed message without breaking the existing signature validity.

   Since it is possible to maintain the integrity of the signature with
   known non-compliant RFC5322 message altered conditions, there is an
   increase possibility of abuse and exploitation of MUA displaying
   information which were not validated by the signature.  Examples may
   be non-compliant RFC 5322 messages containing a 2nd 5322.From or
   2nd Subject headers which were not hash bound to the DKIM signature,
   yet due to the nature of MUAs, the wrong header could be displayed
   to end-users.

   It is unknown how these non-compliant RFC5322 messages will be
   handled by backend MTA receivers and how MUAs will display them.
   It is conceivable, some MTAs will reject these messages while other
   MTAs may accept it but only after it has sanitize the message for
   user display.  Yet other MTAs may be unaware of the multiple
   headers in these non-compliant RFC5322 messages.

   Under unchecked conditions, this can allow an attacker to
   replay a previously sent, signed message with a different Subject,
   From or To field.

   Despite the apparent scope of this requirement, there are
   implementation circumstances in which how DKIM processes
   these non-compliant RFC 5322 messages can not be determined
   until it is known how these messages are first passed or
   reach integrated DKIM processors.

   With an increase alertness of the possibility for these
   non-conforming RFC5322 yet DKIM compliant messages, receiver
   MTA may begin to perform this filtering at an increase level.
   This recommended form of processing will minimize any
   implementation requirement for DKIM to perform this non-compliant
   mail check.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Oct 2010 11:59:13 +0200

On 26/Oct/10 06:58, Murray S. Kucherawy wrote:
> a verifying module might return a syntax error code or arrange not to
> return a positive result even if the signature technically validates.

-1.  How does "might" differ from "MAY"?

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Oct 2010 07:25:11 -0400

> -1.  How does "might" differ from "MAY"?

I think it creates an "IETF procedural" bug and will promote another 
round of reviews or something like that. :)

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 Oct 2010 08:58:49 -0700

On Oct 26, 2010, at 1:49 AM, Hector Santos wrote:

> DKIM does not "allow" additional header fields.

Yes, it does. Section 5.4 of 4871 goes into quite a lot of detail about that, and explains explicitly that you should list a header n+1 times if there are n copies of it already if you don't want to allow more headers to be added, or not if you do.

It's also quite clear about the need to sign user-visible fields.

All we're doing in this thread is pulling those two points together, and adding a dash of observed MUA behaviour w.r.t. messages with multiple Subject headers.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Oct 2010 12:50:02 -0400

>>> This tolerance can be abused......

> Yes, it does. Section 5.4 of 4871 goes into quite a lot of detail about that, and explains explicitly that you should list a header n+1 times if there are n copies of it already if you don't want t…

I see the intent but it can reworded.  I think my nit which I did not 
express, was how the immediate "tolerance" sentence that followed the 
opening text negatively alters its implied meaning.

There is no tolerance. Its a DKIM feature and also a nature act of 
email operations for additional unsigned fields to exist, i.e. 
transport trace fields added to the already signed message.

Maybe a better text might be:

   Per section 5.4, DKIM signed message allows the existence of
   unsigned header fields or additional unsigned headers added
   to the message during the transport process without breaking the
   original signature. This natural email functionality can be abused with
   the introduction of non-compliant RFC 5322 messages with two or
   more headers that can only exist once per RFC 5322.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Oct 2010 10:08:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, October 26, 2010 2:59 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Take two (was Re: Proposal for new text about multiple header issues)
> 

In a bunch of ways.  In particular, though, it is deliberately not RFC2119 language, partly because that's not generally done in Security Considerations since that section is discussion (informative) rather than protocol (normative).

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 Oct 2010 11:20:20 -0700

On Oct 25, 2010, at 9:58 PM, Murray S. Kucherawy wrote:

> The resulting message violates section 3.6 of [MAIL].  The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it will display the newly added header fields rather than those that are part of the originally signed message alongside some “valid DKIM signature” annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field.
>  

Looks fine to me (other than some light wordsmithing of the final paragraph - look like there's a "who" or "who are" missing).

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2010 18:37:53 -0400

+0.999

My only niggle is where you say "dissallowed by section 3.6 of [MAIL]", 
you might want to add a reference to the RFC 2045 which defines the MIME 
headers.

You might also want to mention RFC 4021 which is a laundry list of every 
known message header.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Oct 2010 16:46:09 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 3:38 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

OK.

> You might also want to mention RFC 4021 which is a laundry list of every

What about referring to the IANA header field registry?  4021 was just the primer for that.

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2010 21:23:42 -0400

> What about referring to the IANA header field registry?  4021 was just the primer for that.

Makes sense.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Oct 2010 14:23:25 +0200

On 26/Oct/10 19:08, Murray S. Kucherawy wrote:
>  On Behalf Of Alessandro Vesely
> In a bunch of ways.  In particular, though, it is deliberately not
> RFC2119 language, partly because that's not generally done in
> Security Considerations since that section is discussion
> (informative) rather than protocol (normative).

But it affects the result!  That way a verifier is encouraged to
determine the validity of a signature based on heuristic criteria.

This kind of checking belongs to scam filters a la SpamAssassin.
Now, SA doesn't do it.  Possibly, that's because it's statistically
irrelevant.  AFAIK, SA does not even analyze Authentication-Results,
but re-checks signatures anew.  Why?  Suppose one day the double-From
attack becomes trendy and SA developers will want to write code that
checks for the valid-signature + added-From pattern.  They would never
be able to use A-R, because those results might be flawed by such
non-normative arrangements:  This is where that layer violation hurts.

According to that text, it is strongly advised to have a scam filter
/integrated/ within a DKIM verifier.  Doesn't this slash the value of
stand alone verifiers and A-R fields?

JM2C