Subject: [ietf-dkim] Proposal for new text about multiple header issues

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Oct 2010 21:05:42 -0700

Here's my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list.  This is an addition to -02 directly and does not continue from any of the other proposals.

8.14 Malformed Inputs

The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like.  This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: "Be conservative in what you do, be liberal in what you accept from others."

A number of popular email packages, including MTAs, MLMs, MUAs and so forth, thus forgive or ignore properties of messages that deviate from the standard format.  A frequent example involves violations of Section 3.6 of [MAIL] which specifies minimum and maximum counts for particular header fields.  Thus, a message with more than one From or Subject header field is not a legal email message, but most packages apply some trivial heuristic, e.g. use the first one and ignore the others, to interfere minimally with delivery of mail that might still be desirable to end users.

This can expose those packages to subtle abuse vectors.  For example, two different handlers of a message might identify the Subject field of a message by choosing the first one it finds.   This would always produce the same result, regardless of whether the search is top-down or bottom-up, unless a message had more than one Subject field.  Although [MAIL] specifically disallows this instance, it is tolerated by many mail handling agents, and so the possibility of confusion among implementations exists.

This case becomes more interesting when one considers that a filtering agent might make a filtering decision based on one header field instance but a user agent might display the other.  Knowing that this is the case, an attacker seeking to fool a user might exploit this to get past filters and render false data to a user.

DKIM exacerbates this concern by assigning a signature to part or all of a message.  It is possible that one could craft a message conforming to [MAIL], then affix a DKIM signature to it, and then add header fields atop the message that were not signed.  Since many agents will overlook the fundamental invalidity of such a message, a DKIM verifier might produce a "valid signature" result while some other agent assumes an unsigned field is valid and applies it (e.g., renders it to a user) alongside some indication attesting to the message's validity.  This is especially concerning where one of the fields in question has to do with an identity, such as From or Sender.

Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions:

1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature.  Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it.

2) Refuse outright to sign or verify any message that is not syntactically valid.

3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the "h=" portion of the signature to prevent addition of fraudulent instances.  Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion).

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

---

From: John Levine <[email-masked]>
Date: 25 Oct 2010 04:24:32 -0000

I mostly agree.  (Wow!)

>1) During the handling of a message in conjunction with a DKIM result that indicates a
>valid signature, consider as valid only those fields and the body portion that was
>covered by the signature.  Note that this is not to say unsigned content is not valid,
>but merely that the signature is making no statement about it.
>

Rather than be so absolutist, I'd say "any message with syntax errors that are likely
to cause MUAs or other applications to interpret it inconsistently."

The thought is that two Subject lines is worth rejecting, an extra at
sign in the Message-ID is not.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Oct 2010 21:26:33 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Sunday, October 24, 2010 9:25 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
> 
> I mostly agree.  (Wow!)

Huzzah!

> sign in the Message-ID is not.

I'm fine with that if we think implementers will find it easier to construct a comprehensive "likely" list versus just enforcing the spec.

---

From: Steve Atkins <[email-masked]>
Date: Sun, 24 Oct 2010 21:54:22 -0700

On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote:

> Here’s my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list.  This is an addition to -02 directly and does not continue from any of the other proposals.

I like the sentiment, and the background up to here, but...

> 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature.…

There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is "valid", which isn't the case in general.

Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly).

>  2) Refuse outright to sign or verify any message that is not syntactically valid.

This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail.

>  3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances.  Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion).

This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem.

Something that's more to the point we're concerned about might be more like "A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt to replay a DKIM signed message with different content. DKIM verifier implementors may consider messages that are malformed in this way as unsigned."

Cheers,
  Steve

---

From: "Mark Delany" <[email-masked]>
Date: 24 Oct 2010 21:55:31 -0700

> The universe of email is replete with software that forgives
> messages which do not conform strictly to the grammar that defines
> what valid email looks like.  This is a long-standing practice known
> informally as the robustness principle, originally coined by Jon
> Postel: "Be conservative in what you do, be liberal in what you
> accept from others."

Well, I'm clearly the outlier here, but I think "be liberal" is
protocol nonsense that has been accepted as "conventional wisdom" for
far too long now.

Put another way, "Accept crud and pass it on" constitutes good
protocol design? Gimme a break.

More particularly, DKIM is a security protocol which means that "being
liberal" is entirely antithetical and highly risky to boot.

In short, I don't think any part of DKIM should be based on "be
liberal" because it always trades off security.

Mark.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Oct 2010 22:07:01 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Sunday, October 24, 2010 9:56 PM

You're not the outlier.  I quite agree.

> [...]

What the text is trying to do is show the reader the caveats of the email world that exists today, not agreeing with or attempting to espouse that strategy.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 24 Oct 2010 22:09:55 -0700

> protocol design? Gimme a break.

Jon Postel did not intend the interpretation that folks apply.  As you note, 
carried to the current extreme, it produces silliness.

His statement was meant to refer to the handling of protocol ambiguities.  No 
matter how well a protocol is written, there are places that wind up being 
subject to slightly different interpretation.  Especially during early stages of 
deployment, these ambiguities are discerned incrementally and often not resolved 
for quite awhile.  In these circumstances, code that supports the differing 
interpretations is more robust.

The situation with email comes from the rather different problem that complaints 
are from recipients and directed at their local operators, who have no control 
over the sources of the problems.  So they hack their own code infinitely, to 
reduce local complaints.  That produces the silly cruft.

d/
-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Sun, 24 Oct 2010 22:10:34 -0700

> liberal" because it always trades off security.

A DKIM verifier generates a single bit, "validly signed or not",
and an identifier in the "validly signed" case. It doesn't
pass mail along, well formed or not, nor does it control
whether mail is passed on or not. All it can do is provide an
identity for other pieces of the mail path to consider when
making routing decisions.

The only action a DKIM signer can take with regards to
ill-formed email is to refuse to sign it. The only action a
verifier can take with regards to ill-formed mail is to
consider it unsigned, refusing to provide information
to the rest of the mail delivery system.

Given that, I don't think that either the DKIM signer or
the DKIM verifier are the right place to take a stand against
5322 format violations. And that makes DKIM overall
a poor place to do anything other than mention
specific issues that directly affect the DKIM security model.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Oct 2010 22:15:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Sunday, October 24, 2010 9:54 PM
> To: IETF DKIM WG
> > 1) During the handling of a message in conjunction with a DKIM result
> > that indicates a valid signature, consider as valid only those fields
> > and the body portion that was covered by the signature.  Note that this
> > is not to say unsigned content is not valid, but merely that the
> > signature is making no statement about it.
> 
> There are a couple of issues with this. First, it implies that if a
> DKIM signature does cover a header, then that DKIM signature is saying
> that that header is "valid", which isn't the case in general.

Ah right.  Need to be meticulous here.

How about:

1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not.  Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it.

> Second, this is nearly meaningless operationally. for the sort of
> attack that's been envisioned (showing different author or subject in
> an apparently signed message), as there's no real way to consider any
> particular field as valid or invalid (unless you're communicating the
> information all the way to the MUAs display code, or you're deleting
> headers in transit - which are both possibilities, but ones that would
> need to be called out explicitly).

The text is intended to be generic, referring to any entity that might consume a DKIM "pass" result.  The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically.

> This is overly strong, as a lot of messages that are not 5322 valid are
> wanted (bare linefeeds, amongst other issues). Encouraging signers or
> verifiers to deny the existence of a DKIM identity in those cases just
> makes it harder to distinguish between wanted invalid mail and unwanted
> invalid mail.

This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting.  If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically.

> Something that's more to the point we're concerned about might be more
> like "A mail system that considers DKIM signatures during mail delivery
> should treat with suspicion any email that has multiple copies of any
> header where RFC 5322 requires they have no more than one, as it may be
> an attempt to replay a DKIM signed message with different content. DKIM
> verifier implementors may consider messages that are malformed in this
> way as unsigned."

Maybe that can be some example-type text tacked on to the second bullet point?

---

From: Steve Atkins <[email-masked]>
Date: Sun, 24 Oct 2010 22:35:59 -0700

> 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the s…

That still expands the API from the DKIM verifier quite a lot - it requires the verifier to explicitly list which headers are signed, and which aren't (that the h= field doesn't do that is what we're having problems with). It would also require that to be pushed all the way downstream to other pieces of software, perhaps via something similar to an extended Authentication-Results type of header.

That's not impossible, but seems very complex for the specific problem we're considering - we just need to communicate "This message violated 5322, specifically in a way that makes us think the sender is trying to game DKIM" (either by flagging the mail as syntactically invalid and suspicious at some point in the mail stream, or invalidating the DKIM signature).

> The text is intended to be generic, referring to any entity that might consume a DKIM "pass" result.  The particularly interesting ones are of course the MUAs and anything that does authentication…

If we need to communicate a list of "valid" headers to downstream consumers of a DKIM "pass" result it's a lot more complex than a simple pass/fail and we'd need to consider what that API might be (partly so we're clear on what data in addition to a "DKIM pass, here's your d=" we're communicating).

> This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting.

Yup. It's a backdoor SHOULD, and I don't like it for the same reason :).

>  If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically.

I'm more concerned with the suggestion that *any* violation of 5322 (or 2045 and friends - it's all syntax) is grounds for refusing to validate a message. I think that DKIM verifiers refusing to pass on a d= identifier due to trivial format violations is likely to reduce the quality of the mailstream rather than increase it. 

(Those violations may well be grounds for another part of the mail handler to reject the mail altogether, but that's outside DKIMs main job of providing an identifier to help the downstream mail handlers make informed decisions.)

Focussing on just those issues that may affect the DKIM security model (which, if we kill off l=, is likely to just be adding unsigned headers) seems like it'd push implementors in a more useful direction.

> Maybe that can be some example-type text tacked on to the second bullet point?

Could be. Something a bit more specific would help implementors.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Oct 2010 01:45:40 -0400

> liberal" because it always trades off security.

Really, its an inappropriate attempt in a history lesson and it 
actually doesn't apply here.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Oct 2010 22:50:34 -0700

> Sent: Sunday, October 24, 2010 10:36 PM
> To: IETF DKIM WG
> That still expands the API from the DKIM verifier quite a lot - it
> requires the verifier to explicitly list which headers are signed, and
> which aren't (that the h= field doesn't do that is what we're having
> problems with). It would also require that to be pushed all the way
> downstream to other pieces of software, perhaps via something similar
> to an extended Authentication-Results type of header.
> 
> That's not impossible, but seems very complex for the specific problem
> we're considering - we just need to communicate "This message violated
> 5322, specifically in a way that makes us think the sender is trying to
> game DKIM" (either by flagging the mail as syntactically invalid and
> suspicious at some point in the mail stream, or invalidating the DKIM
> signature).
> [...]

You seem to have some specific ideas in mind already.  Can you propose some alternate text?

---

From: John Levine <[email-masked]>
Date: 25 Oct 2010 14:47:12 -0000

>and an identifier in the "validly signed" case.

Well, actually, if you read 4871, it also produces an edited version
of the message.  As I suggested in my message a few days ago, I don't
think that's what we intended, and we should fix 4871bis so it doesn't
say that any more.

> And that makes DKIM overall a poor place to do anything other than
>mention specific issues that directly affect the DKIM security model.

Agreed.

R's,
John

---

From: John Levine <[email-masked]>
Date: 25 Oct 2010 14:53:23 -0000

>I'm fine with that if we think implementers will find it easier to construct a
>comprehensive "likely" list versus just enforcing the spec.

It's not easier but I'm with Steve here.  People are not likely to
implement a spec that says that verifiers fail due to trivial syntax
errors in the message.

At this point, the only things I'm aware of that present a risk of bad
rendering are duplicate headers and l= that doesn't cover the whole
message.  That list may grow in the future, but I doubt it will grow
very fast.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Oct 2010 07:54:12 -0700

On 10/25/2010 7:47 AM, John Levine wrote:
> of the message.

Please cite the text in the specification that defines this output process 
and/or result.

d/
-- 

   Dave Crocker

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 25 Oct 2010 16:16:25 +0100

> and an identifier in the "validly signed" case.

Actually, my verifier produces two bits: one for the headers, and one for 
the body. In terms of authentication, that might not mean much. It is 
useful for debugging, though.

It also says if the public key was unavailable, or contained a syntax error:

For what it's worth, today, on one cluster, I see these counts:
  12 invalid - public key record (currently?) unavailable
  19 invalid - syntax error in public key record
  31 verification failed - body hash mismatch (body probably modified in 
transit)
 285 verification failed - signature did not verify (headers probably 
modified in transit)
1776 verification succeeded

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Oct 2010 08:56:29 -0700

> useful for debugging, though.

We need to be careful to distinguish between software and protocol.

Software is free to do whatever it wants.

The DKIM Signing specification, however, deals with constrained, standardized 
behavior.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Oct 2010 09:55:47 -0700

> You seem to have some specific ideas in mind already.  Can you propose some alternate text?

Sure. Taking into account some of the other feedback too:

---

8.14 Malformed Inputs

DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, 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] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with   a different Subject, From or To field.

Because of this, inbound mail system implementors should consider defending against this sort of replay attack by either

1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject).

2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed.

Senders who feel that their messages might be particularly vulnerable to this sort of attack who don't want to rely on receiver filtering of invalid messages can ensure that adding additional headers will break their DKIM signature by including two copies of the headers they're concerned about in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further discussion.

---

It's significantly less subtle than your phrasing, but I think bluntness and clarity win out for a security discussion.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Oct 2010 12:19:27 -0700

> Sent: Monday, October 25, 2010 9:56 AM
> To: IETF DKIM WG
> DKIM allows additional headers to be added to a signed message without
> breaking the signature. This tolerance can be abused during a replay
> attack by adding additional copies of headers that are displayed to the
> end user, such as From or Subject, to an already signed message in a
> way that doesn't break the signature.

I'd strike "during a replay attack" because, as some have noted, the attack can be constructed deliberately on an original message.

I'd also probably want to include some of my original text that sets up why various agents are so permissive today.

> The resulting message violates section 3.6 of [MAIL] so the way it will
> be handled and displayed by an MUA is unpredictable - but in some cases
> they will display the newly added headers rather than those that are
> part of the originally signed message. This might allow an attacker to
> replay a previously sent, signed message with a different Subject,
> From or To field.

It's also not specific to MUAs.  Filtering agents can be similarly duped.

> 1) Rejecting or treating as suspicious any message that has multiple
> copies of headers that are disallowed by section 3.6 of [MAIL],
> particularly those that are displayed to the end user (From, To, Cc,
> Subject).
> 
> 2) Treating any message that has multiple copies of headers that are
> disallowed by section 3.6 of [MAIL] as not DKIM signed.

These almost say the same thing to me.  For example, "treat as unsigned" could be rolled into "treat as suspicious".  And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME.

If you concur, I'll take another run at it.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Oct 2010 12:53:30 -0700

> I'd strike "during a replay attack" because, as some have noted, the attack can be constructed deliberately on an original message.

The real risk here is that someone can present a message as signed by someone trustworthy that has content different to that which was provided by the trusted signer. If the entity adding the additional content is the original signer, it may be a message composition bug, but it's not really any sort of attack on DKIM.

Striking "replay attack" might make it less clear what the actual risk is, rather than more clear.

("... can be abused, e.g. during a replay attack, by adding ..." ?)

> I'd also probably want to include some of my original text that sets up why various agents are so permissive today.

I'm not sure the history adds anything, and briefer tends to lead to a clearer call to action.

(And it annoys Mark, and may be continuing a misinterpretation of the robustness principle and...).

> It's also not specific to MUAs.  Filtering agents can be similarly duped.

They can, yes, though I'm not sure that's needed to explain why this may be a bad thing to allow.

> These almost say the same thing to me.  For example, "treat as unsigned" could be rolled into "treat as suspicious".  And I'd prefer to show 3.6 as an example of a more general problem, in case lat…

They're somewhat different. The first case involves recognizing that such messages are likely an attempt to be deceitful, and hence that the mail is unwanted. It's an approach that affects parts of the mail delivery system outside of DKIM, and will directly affect mail routing and delivery, and so can only be implemented by a broader system architect, not by a DKIM implementor.

The second simply removes the DKIM-related benefit to this sort of attempt at deceit, removing the benefit of doing it. It doesn't make any broader judgement, and it can be handled entirely inside the DKIM verifier, without having any behavior change in the rest of the mail system, other than that implied by a lack of signature.

> And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME.

I'd prefer to stick to actual concerns, for now - stressing theoretical risks for which we have no idea how they could be implemented is a slippery slope. (I'm assuming that "l=" is going to be removed - if not, that would change things considerably as far as the likelihood of some sort of mime-related body change).

> If you concur, I'll take another run at it.

Sure.

Cheers,
  Steve

---

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

> Sent: Monday, October 25, 2010 12:54 PM
> To: IETF DKIM WG
> > I'd strike "during a replay attack" because, as some have noted, the
> > attack can be constructed deliberately on an original message.
> 
> The real risk here is that someone can present a message as signed by
> someone trustworthy that has content different to that which was
> provided by the trusted signer. If the entity adding the additional
> content is the original signer, it may be a message composition bug,
> but it's not really any sort of attack on DKIM.
> 

Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target?

> may be a bad thing to allow.

Focusing on the MUA case might inadvertently suggest to implementers of other components that this is not a concern for them.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Oct 2010 14:12:24 -0700

> Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target?

Not really, no. Signing the From: field means nothing other than that it is the same as when it was sent.

I can sign mail with d=blighty.com and "From: [email-masked]" without needing to play any games with multiple headers

The only interesting attack in this entire situation is the ability to take a message signed by a high-reputation domain, so that it'll get delivered to the inbox, and to replace the Subject: (and possibly From:) with your own payload.

> Focusing on the MUA case might inadvertently suggest to implementers of other components that this is not a concern for them.

True. Though it really shouldn't be a significant concern for them, as filtering agents that are DKIM aware (should anyone create such a thing) and have a valid DKIM identity will likely use that in preference to, say, the From: field. And if the filtering agent is not DKIM aware, it's not an issue.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Oct 2010 14:53:14 -0700

> The only interesting attack in this entire situation is the ability to take a message signed by a high-reputation domain, so that it'll get delivered to the inbox, and to replace the Subject: (and…
Disagree.  It could be signed by a large domain that is unlikely 
blocked, where the high value domain can then be spoofed because of a 
poorly defined DKIM verification process, regardless where the DKIM 
verification process happens to be located.
> True. Though it really shouldn't be a significant concern for them, as filtering agents that are DKIM aware (should anyone create such a thing) and have a valid DKIM identity will likely use that i…
DKIM verification is still  DKIM verification regardless where this 
process is located.  Stop hand waving.  This process MUST be correctly 
defined to protect the consumers of these results.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Oct 2010 14:48:12 -0700

On 10/24/10 9:05 PM, Murray S. Kucherawy wrote:
>
> Here’s my proposal for a section in Security Considerations to talk 
> about the malformation issues that have been discussed on the list. 
> This is an addition to -02 directly and does not continue from any of 
> the other proposals.
>
> 8.14 Malformed Inputs
>
> The universe of email is replete with software that forgives messages 
> which do not conform strictly to the grammar that defines what valid 
> email looks like. This is a long-standing practice known informally as 
> the robustness principle, originally coined by Jon Postel: “Be 
> conservative in what you do, be liberal in what you accept from others.”
>
> A number of popular email packages, including MTAs, MLMs, MUAs and so 
> forth, thus forgive or ignore properties of messages that deviate from 
> the standard format. A frequent example involves violations of Section 
> 3.6 of [MAIL] which specifies minimum and maximum counts for 
> particular header fields. Thus, a message with more than one From or 
> Subject header field is not a legal email message, but most packages 
> apply some trivial heuristic, e.g. use the first one and ignore the 
> others, to interfere minimally with delivery of mail that might still 
> be desirable to end users.
>
> This can expose those packages to subtle abuse vectors. For example, 
> two different handlers of a message might identify the Subject field 
> of a message by choosing the first one it finds. This would always 
> produce the same result, regardless of whether the search is top-down 
> or bottom-up, unless a message had more than one Subject field. 
> Although [MAIL] specifically disallows this instance, it is tolerated 
> by many mail handling agents, and so the possibility of confusion 
> among implementations exists.
>
> This case becomes more interesting when one considers that a filtering 
> agent might make a filtering decision based on one header field 
> instance but a user agent might display the other. Knowing that this 
> is the case, an attacker seeking to fool a user might exploit this to 
> get past filters and render false data to a user.
>
> DKIM exacerbates this concern by assigning a signature to part or all 
> of a message. It is possible that one could craft a message conforming 
> to [MAIL], then affix a DKIM signature to it, and then add header 
> fields atop the message that were not signed. Since many agents will 
> overlook the fundamental invalidity of such a message, a DKIM verifier 
> might produce a “valid signature” result while some other agent 
> assumes an unsigned field is valid and applies it (e.g., renders it to 
> a user) alongside some indication attesting to the message’s validity. 
> This is especially concerning where one of the fields in question has 
> to do with an identity, such as From or Sender.
>
> Because of this, DKIM implementers are strongly advised to apply one 
> or more of the following design decisions:
>
Bad advice. There is no other email component that can be relied upon to 
restore flawed DKIM verification results, nor should DKIM relegate 
determination of DKIM result validity to subsequent consumers. This 
would be expecting all subsequent stages of email, represented by 
thousands of different applications, to repeat tests that now MUST be 
made to mitigate exploits. Without a MUST requirement in the 
verification process with respect to multiple From header fields, no 
DKIM results can be trusted for subsequent display or sorting 
processing. Nor should these processes be expected to conform with the 
DKIM bottom-up selection of headers that MUST be singular to be 
compliant with RFC5322.
> 2) Refuse outright to sign or verify any message that is not 
Good advice. However, without a MUST normative language, DKIM results 
will be prone to attack. It is not reasonable to suggest consumers of 
DKIM results check "something" "somewhere". This is NOT about enforcing 
compliance, this is about ensuring safe and actionable DKIM results. 
This can only be specified by the DKIM protocol. While lack of RFC5322 
compliance might go unnoticed, a DKIM verifier MUST NEVER indicate a 
message with multiple From headers receive a PASS.Policy components 
could then indicate specific message handling.
>
> 3) For any header field listed in Section 3.6 of [MAIL] as having an 
> upper bound on the number of times it can appear, include the name of 
> that field one extra time in the “h=” portion of the signature to 
> prevent addition of fraudulent instances. Any attachment of such 
> fields after signing would thus invalidate the signature (see Section 
> 3.5 and 5.4 for further discussion).
>
Incomplete advice. This only provides partial protection, since it does 
not prevent spoofing of a From header where an attacker controls or 
utilizes a domain that does not include repeated From header entries 
within the h= parameter.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 25 Oct 2010 20:48:41 -0400

> I can sign mail with d=blighty.com and "From: [email-masked]" without needing to play any games with multiple headers

Let's say your message has two From lines, one from [email-masked], one 
from [email-masked], and you sign the first with d=blurfle.net. 
Perhaps blurfle.net even publishes discardable ADSP.

My concern would be that filtering agents might notice the blurfle header 
and signature and deem it harmless, but an MUA would show the ebay header.

In any event, I think it's reasonable to say that DKIM signers shouldn't 
sign a message with an extra From or Subject header, and verifiers 
shouldn't say the signature on such a message is good, even if it 
validates technically.  I dug through my message archives last week, and I 
don't think I've ever seen a legit message with that flaw, so it's hard to 
think of a reason to cut such messages any slack.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Oct 2010 18:09:23 -0700

On Oct 25, 2010, at 5:48 PM, John R. Levine wrote:

> Let's say your message has two From lines, one from [email-masked], one from [email-masked], and you sign the first with d=blurfle.net.

> My concern would be that filtering agents might notice the blurfle header and signature and deem it harmless,

If the filtering agent recognises blurfle.net then that would make blurfle.net "someone trustworthy", and reduces to exactly the situation I was discussing 4 posts upstream. ("The real risk here is that someone can present a message as signed by someone trustworthy..."). 

If they've never seen blurfle.net before, then there's no reason to consider the signer trustworthy and your hypothetical filtering agent is broken.

> but an MUA would show the ebay header.

> In any event, I think it's reasonable to say that DKIM signers shouldn't sign a message with an extra From or Subject header,

That doesn't really add much value, as you can always grab the signed message, add a header and resend it (unless you're also planning on mandating h=from:from:subject:subject).

It's a perfectly reasonable policy for a DKIM signer to have, though.

> and verifiers shouldn't say the signature on such a message is good, even if it validates technically.  

Works for me, at least at the should-as-opposed-to-SHOULD level. 

I've said as much several times, and the only disagreements I've seen are people who are saying that that's not strict enough, and that DKIM verifiers also shouldn't verify a message that has, for example, bare linefeeds in it or a base 64 encoded section with an eighty character line in it.

> I dug through my message archives last week, and I don't think I've ever seen a legit message with that flaw, so it's hard to think of a reason to cut such messages any slack.

Cheers,
  Steve

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, October 25, 2010 2:48 PM
> determination of DKIM result validity to subsequent consumers.

But neither of those was the suggestion.

> > that field one extra time in the "h=" portion of the signature to

I'm having trouble parsing that.  Please propose alternate text, or show an example of what you're describing.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 26 Oct 2010 12:13:43 +0100

--On 25 October 2010 09:55:47 -0700 Steve Atkins <[email-masked]> 
wrote:

> end user, such as From or Subject, to an already signed message in a way
> that doesn't break the signature.
>
> they will display the newly added headers rather than those that are part
> of the originally signed message. This might allow an attacker to replay
> a previously sent, signed message with   a different Subject, From or To
> field.

My guess is that for the set of MUAs that aren't paying attention to DKIM 
signatures, random placement of the second header will ensure that the 
wrong header is displayed 50% of the time. Familiarity with a few popular 
MUAs (assuming that they deterministically display either the first or the 
last) would achieve better than 50% display rates. Heck, if you insert one 
header before the signed header, and one after, then you might well get a 
100% display rate across all MUAs that aren't aware of this problem.

It's conceivable that "unpredictable" is

> Because of this, inbound mail system implementors should consider
> defending against this sort of replay attack by either
>

And, "Date", please? It also meets those criteria. Some messages might have 
quite different meanings when the date is changed. Perhaps a message with 
instructions to call a premium rate phone number, "by Friday". Such a 
message might be repurposed after the number has changed hands.

Or, a political statement might have very different implications at a later 
date. For example, I saw a tweet recently saying that a UK coalition 
government minister (a Liberal Democrat) had called another government 
minister (a Conservative) "incompetent". It turned out that this was true, 
but the linked article was written months before the recent general 
election, before the coalition was formed. So, the implications were very 
different than if the statement were made today.

> Senders who feel that their messages might be particularly vulnerable to
> this sort of attack who don't want to rely on receiver filtering of
> invalid messages can ensure that adding additional headers will break
> their DKIM signature by including two copies of the headers they're
> concerned about in the signature (e.g. "h= ...
> from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further
> discussion.

h= ... from:from:to:to:subject:subject:date:date ...

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Oct 2010 16:30:14 +0100

>>> I can sign mail with d=blighty.com and "From: [email-masked]"  
>>> without needing to play any games with multiple headers
>>
>> Let's say your message has two From lines, one from [email-masked],  
>> one from [email-masked], and you sign the first with d=blurfle.net.
>
>> My concern would be that filtering agents might notice the blurfle  
>> header and signature and deem it harmless,
>
......

>> In any event, I think it's reasonable to say that DKIM signers  
>> shouldn't sign a message with an extra From or Subject header,
>
> That doesn't really add much value, as you can always grab the signed  
> message, add a header and resend it (unless you're also planning on  
> mandating h=from:from:subject:subject).

No, but you can then say that verifiers should reject it because it  
shouldn't have been signed (in that form) in the first place.

Essentially, you need proper wording in TWO places; something like:

A. Signers MUST NOT sign a message where any header field included in the  
'h=' tag and which is a <once-only> header occurs more than once in the  
mesage.

B. Verifiers MUST return PERMFAIL if the signature does not verify  
{obviously} OR if the signature had been improperly applied (in particular  
if A had been violated).

where <once-only> implies some list of headers which we can argue about  
later (obviously including From:, Subject:, etc and perhaps defined in  
terms of RFC5322, RFC2045, etc).

Observe that this catches all the Bad Actors currently under discussion,  
both those that deliberately violate 5322, and those that deliberatley  
violate my rule A.

Moreover, there is NO LAYERING VIOLATION, because my rule B is merely  
enforcing my rule A, and both rules would be a part of 4871-bis.
>> even if it validates technically.

Exactly.
> Works for me, at least at the should-as-opposed-to-SHOULD level.

But why not at the SHOULD/MUST level? What I have suggested should stop  
dead all forms of the attack that have been suggested. What more could you  
want?
>
> I've said as much several times, and the only disagreements I've seen  
> are people who are saying that that's not strict enough, and that DKIM  
> verifiers also shouldn't verify a message that has, for example, bare  
> linefeeds in it or a base 64 encoded section with an eighty character  
> line in it.

Indeed, which is why my suggested two rules carefully stopped short of  
that.

-- 
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: Douglas Otis <[email-masked]>
Date: Wed, 27 Oct 2010 18:36:27 -0700

On 10/25/10 9:36 PM, Murray S. Kucherawy wrote:
> > On Monday, October 25, 2010 2:48 PM, Douglas Otis wrote:
> >> 1) During the handling of a message in conjunction with a DKIM
> >> result that indicates a valid signature, consider as valid only
> >> those fields and the body portion that was covered by the
> >> signature. Note that this is not to say unsigned content is not
> >> valid, but merely that the signature is making no statement about
> >> it.
> >
> > Bad advice. There is no other email component that can be relied
> > upon to restore flawed DKIM verification results, nor should DKIM
> > relegate determination of DKIM result validity to subsequent
> > consumers.
>

A DKIM Signature Verification returning PASS when there are multiple 
 From header fields provides information that REQUIRES additional checks 
before it can be safely employed by _any_ consumer of DKIM results.  In 
nearly every case, such a message is the result of a bad actor 
attempting to exploit the lack of essential conformance checks.  
Subsequent checking of DKIM results represents a clear protocol layer 
violation, where this checking SHOULD be done by DKIM.  Suggesting that 
omitting these checks is okay represents Bad Advice.  The DKIM protocol 
MUST require checks that are critical to the safe use of DKIM results, 
and not simply document the mistaken omission of these checks that 
implies subsequent consumers of DKIM results are expected to make these 
checks instead, or expected to have a header selection process of what 
should be a singular header field conform with DKIM's bottom-up processing.

> >> 3) For any header field listed in Section 3.6 of [MAIL] as having
> >> an upper bound on the number of times it can appear, include the
> >> name of that field one extra time in the "h=" portion of the
> >> signature to prevent addition of fraudulent instances. Any
> >> attachment of such fields after signing would thus invalidate the
> >> signature (see Section 3.5 and 5.4 for further discussion).
> >
> > Incomplete advice. This only provides partial protection, since it
> > does not prevent spoofing of a From header where an attacker
> > controls or utilizes a domain that does not include repeated From
> > header entries within the h= parameter.
>
>  I'm having trouble parsing that. Please propose alternate text, or
>  show an example of what you're describing.

I'll repeat the example given previously.  The multiple listing of a 
header in the h= parameter can not mitigate exploitation of DKIM PASS 
results where a valuable domain is prefixed to that of large domain.  
The large domain is unlikely concerned by possible presence of a 
pre-pended header field, where their decision not to include multiple 
listing for a message clearly not compliant with RFC5322.  In other 
words, this leaves DKIM results open to exploitation.

From: [email-masked]
From: [email-masked]
DKIM-Signature: h=from, d=big-isp.com, ...

Reputation can not fix this problem.  Fobbing this onto the consumers of 
DKIM results goes against the goal of increasing trust in email, and 
against the spirit of doing our best at providing accurate results.  
Let's fix our mistake.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Oct 2010 23:53:51 -0400

> against the spirit of doing our best at providing accurate results.  

The lack of focus for 1st party domain protection is what allowed this 
issue to fall through the crack.  We tried our best to make DKIM a 
pure signing mechanism with an open ended "implicit policy" of 
unrestricted resigners, remolding the specs with out of scope "wink 
wink" design goals.  MLM "allowance" or "tolerance" became a dominant 
goal over the principle benefit DKIM can provide - 1st party DOMAIN 
protection.

The solution is an integrated solution.  DKIM itself can not solve 
this.  At this point, what's missing are HANDLING provisions for DKIM 
verifiers.  A real POLICY protocol with 3rd party considerations is 
really the only thing that can help resolve this problem.  Even 
Reputation Vendors can help here but they need to support POLICY too. 
Instead, the pressure has been to eliminate it.

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Oct 2010 11:44:05 -0700

> Instead, the pressure has been to eliminate it.
Agreed.  But additional handling provisions are meaningless without DKIM 
PASS offering an actionable state.  Unless trivial exploits allowed by 
multiple (singular) header fields are assured to receive PERMFAIL, DKIM 
will not offer a basis for message handling or annotation.

There is ongoing effort within the TPA-Label scheme.  Several companies 
also want an authorized third-party reporting mechanism as well, which 
can be combined with the TPA-Label extensions.   Third-party information 
needs to be made generally available before such policy assertions 
become easy for typical administrators.  The difficult policy issues 
involve multiple domains when seeking meaningful and concise handling 
decisions without disrupting legitimate message sources.  The relatively 
small number of legitimate sources makes this a tractable problem, 
especially for those who track these sources.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Oct 2010 12:05:25 +0200

> DKIM-Signature: h=from, d=big-isp.com, ...

Besides RFC 5322 compliance, how is this different from a traditional 
unsigned spoofed "From: [email-masked]"?  Having just a 
signature doesn't mean much, and spelling how to match signature and 
 From field is ADSP's job, even in corner cases.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Oct 2010 12:39:51 +0200

On 25/Oct/10 06:54, Steve Atkins wrote:
>> name of that field one extra time in the “h=” portion of the
> This works, and is definitely on the right track as it's looking at
> the specific problem rather than broad 5322 compliance, but feels
> like a hack workaround by the signer for a problem that's simpler
> for the receiver to deal with directly.

Implementations, e.g. OpenDKIM, may be configured with a list of 
fields-to-sign, rather than the exact content of the h= tag.  Thus, 
such a signer can double the occurrence of singleton fields as part of 
DKIM-Signature creation. Or it can slightly improve its configuration 
grammar in order to let the user specify when fields are to be bounded 
by adding an extra instance of their name in the h= tag.  We can 
sprinkle any amount of syntactic sugar on that...

I think that, although it may seem simpler to deal with the problem at 
the receiver's, we've seen it actually is not simpler at all.

> It is something we can encourage that's strictly within the bounds
> of a DKIM spec, but that doesn't make it the ideal solution to the
> problem.

Why it's not ideal?

Even having to specify "From" may be felt as a nuisance, since it's 
mandatory already.  Kay Engert's serendipitous reinvention of DKIM, 
http://kuix.de/spamsalt/, provides for a fixed set of signed header 
fields: does that make spamsalt less hacky than DKIM?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html