Subject: [ietf-dkim] FW: Getting resolution on the "double header" issue

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Feb 2011 12:52:24 -0800

This is the last text that I circulated on the bogus header matter, in reply to Barry's proposed path to resolution.  The group was pretty exhausted from debate at that point so there was little response.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, November 08, 2010 1:20 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Getting resolution on the "double header" issue
> 
> Proposal:
> 
> 1. The DKIM spec is responsible for describing the problem in terms of
> how it relates to signed and unsigned versions of the fields.  That's
> the stuff in 8.14.

Concur.  I worked through an 8.14 proposal a couple of weeks ago using input from the list.  The last text I have was:

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 who 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.

Specific validity rules for all known header fields can be gleaned from the IANA "Permanent Header Field Registry" and the reference documents it identifies.

> 2. The DKIM spec should probably say that signers need to sign valid
> messages, and, therefore, SHOULD NOT sign things like this.  Text
> along the line of this might work well:
> "Signers SHOULD take reasonable steps to ensure
> that the messages they're signing are valid according to [RFC 5322,
> etc]."  Leaving the definition of "reasonable" out allows flexibility.
> It may be waffly, but I like the approach in this case.

Works for me.  How about:

3.10. Input Requirements

DKIM's design is predicated on valid input.  Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [MAIL], [MIME], and any other relevant message format standards.  See Section 8.14 for additional discussion and references.

> 3. It'd be reasonable for the DKIM spec to remind verifiers that
> signers aren't supposed to sign stuff like this, so they might
> consider that when deciding what to do with it after verification.
> It'd be reasonable to remind them of this particular case.  But
> I think that all ought to be informative text.

Yup; the above two amendments cover both cases.

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

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Feb 2011 16:33:54 -0500

On Wednesday, February 16, 2011 03:52:24 pm Murray S. Kucherawy wrote:
> This is the last text that I circulated on the bogus header matter, in
> reply to Barry's proposed path to resolution.  The group was pretty
> exhausted from debate at that point so there was little response.
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Barry Leiba Sent:
> > Monday, November 08, 2010 1:20 AM
> > To: IETF DKIM WG
> Concur.  I worked through an 8.14 proposal a couple of weeks ago using
> input from the list.  The last text I have was:
> 
> 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 who 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.
> 
> Specific validity rules for all known header fields can be gleaned from the
> IANA "Permanent Header Field Registry" and the reference documents it
> identifies.
> 
> DKIM's design is predicated on valid input.  Therefore, signers and
> verifiers SHOULD take reasonable steps to ensure that the messages they
> are processing are valid according to [MAIL], [MIME], and any other
> relevant message format standards.  See Section 8.14 for additional
> discussion and references.
> 

+1.

Scott K

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 18 Feb 2011 13:11:07 -0500

> Yup; the above two amendments cover both cases.

+1

-- 
Jeff Macdonald
Ayer, MA