Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Oct 2010 10:47:04 -0700

> 	Title		: DomainKeys Identified Mail (DKIM) Signatures
> 	Author(s)	: D. Crocker, M. Kucherawy, T. Hansen
> 	Filename	: draft-ietf-dkim-rfc4871bis-02.txt
...
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-02.txt

Folks,

Attached is the diff of the -02 version with the -01 one.

d/
-- 

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

---

From: [email-masked]
Date: Mon, 11 Oct 2010 10:30:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Pages		: 76
	Date		: 2010-10-11
	
DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message.  This can be an author's organization, an operational relay
   or one of their agents.  DKIM separates the question of the identity
   of the signer of the message from the purported author of the
   message.  Assertion of responsibility is validated through a
   cryptographic signature and querying the signer's domain directly to
   retrieve the appropriate public key.  Message transit from author to
   recipient is through relays that typically make no substantive change
   to the message content and thus preserve the DKIM signature.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Oct 2010 13:44:40 -0700

There's a Working Group Last Call in effect for -01.  Should we:

- Continue to direct comments at -01
- Comment on -02 instead
- or will the WGLC be restarted on the -02 draft?

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Oct 2010 14:33:11 -0700

> - or will the WGLC be restarted on the -02 draft?

Just my personal opinion:

The revision is based on LC comments so far.  Since ultimately the working group 
has to agree on the document, it's probably more efficient for further comments 
to be on -02.  (Efficient, but not necessary, of course,)

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Oct 2010 02:46:42 -0400

> - or will the WGLC be restarted on the -02 draft?

I think it's not necessary for us to restart, but reviews should now
go against -02.

There are only two significant changes between -01 and -02 ... most of
the changes are just updating the references.  The substantive changes
are:
1. The addition of the paragraph that begins "Similarly, a message
that is not compliant with RFC5322," near the end of 5.3.
2. The addition of 8.14.

If anyone feels they need more time to review those than the currently
WGLC provides, please let the chairs know.

Dave:
There's an error in the new paragraph in section 5.3; the first
sentence appears to have been fragmented.  It reads thus: "Similarly,
a message that is not compliant with RFC5322, RFC2045 correct or
interpret such content."
Please post the correct version here, so reviewers have it handy, and
have it ready for any subsequent update.

Barry, as chair

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 Oct 2010 06:00:19 -0700

> have it ready for any subsequent update.

Oh boy.  Very sorry folks.

The full text reads:

>             <t>Similarly, a message not compliant with RFC5322, RFC2045 and
>                RFC2047, can be subject to attempts by intermediaries to correct
>                or interpret such content. See the Section 8 of [SUBMISSION] for
>                examples of changes that are commonly made. Such "corrections"
>                may break DKIM signatures or have other undesirable effects.
>                Therefore, a DKIM agent SHOULD confirm that a message is
>                compliant with those specifications prior to processing. </t>

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 09:21:31 -0400

In the new section 8.14, I believe there is many statements that are 
hardly true, but subjective and written by someone begging to pass the 
buck with conflictive arguments.

DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM.  Lets play fair 
with all parties.

1) Contradiction

      Many email implementations do not enforce [RFC5322] with 
strictness.	
      As discussed in Section 5.3 DKIM processing is predicated on a 
valid	
      mail message as its input.

If DKIM designers knew there were many email implementations with less 
than strict enforcement and strictness was an requirement, then DKIM 
started with a problem it ignored to address.  Either it was ignorant 
or poor engineering.

Reword this.

2) There is no intent.

     With the intent of providing a better user experience, many 
agents tolerate
     these violations and deliver the message anyway.

There is no intent by anyone to allow violations. This isn't a game. 
People have commercial systems and do not just say "Hell, lets not 
follow rules."  There are just things that are not expected just like 
DKIM didn't expect it.

Also keep in mind, many systems do reject or flag bad RFC 
822/8222/5322 messages.  The issue here is that DKIM was a loophole 
even against compliant RFC5322 checking systems as the President Obama 
message shown.

Reword this.

3) Philosophical conflictive parenthetical sentence:

   (This can also be taken as a  demonstration that DKIM is not designed
    to support author validation.)

It demonstrated the opposite. Please, DKIM *does not reduce* the long 
historical power of author of the message in any shape or form.   The 
AUTHOR will always be a powerful part of the message. DKIM does 
validate the author and this requirement is reaffirmed by its special 
consideration - the only REQUIRED header binding.  Until the 5322.From 
binding is made optional, it will always continue to be very important.

In addition, the statement is protocol inconsistent with other 
existing and new internet protocols that do and continue to make the 
author a powerful part of the message.

Please STOP trying to disassociate the 5322.From from the long time 
email message communication between parties.

Please remove this "Oh by the way.." parenthetical statement.

Here is my reworded text. I would not give the "How to Exploit." Let 
the bad guy figure it out.  No blaming anyone.

   8.14.  Attacks Involving Addition of Header Fields

   Historically, email implementations have been tolerant of less than 
100%
   strict RFC822, RFC2822 and RFC5322 formatted messages.  There are
   certain elements within DKIM predicated on having a valid RFC
   5322 messages.

   For example, a message with a single From: header field is expected and
   required by DKIM.  Having more than one From: header violates	
   Section 3.6 of [RFC5322] and should be rejected or flagged by
   receiving MTA systems and not passed on to DKIM signing engines.

   A signer wishing to be resistant to any specific multiple header
   attacks can include in the signed header field list an additional
   instance of each field that was present at signing.  For example, a
   proper message with one From: field could be signed using 
"h=From:From:..."
   Because of the way header fields are canonicalized for input to the
   hash function, this would prevent additional fields from being added,
   after signing,  as this would render the signature invalid.

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Oct 2010 11:47:34 -0400

Hector says...
> started with a problem it ignored to address.  Either it was ignorant

That's not true at all.  It's common and reasonable for newer
protocols to tighten things up and require stricter adherence to the
older protocols.  New features often make it unwise or incorrect to
treat earlier requirements loosely.  This is one of those cases, and
in earlier versions of DKIM work there was certainly wording about
requiring valid RFC 2822 (at the time) messages.

> 2) There is no intent.

There is, quite often.  It's very often the case that things on the
receiving side tolerate malformed messages *specifically* to avoid
rejecting more messages than necessary.  "With the intent of providing
a better user experience," is absolutely correct in a great many
cases.  And we're telling verifiers that when you add DKIM, that
tolerance might now be unwise.

>    to support author validation.)

Yeh, that's the only part I agree on (though not with the reasoning
that follows).  I'm ambivalent about having that parenthetical
statement in there.  I'd like to see some consensus about whether to
leave it or keep it.

> the bad guy figure it out.  No blaming anyone.

-1; I like the wording that's there.

I also look at the description of the attack not as helping "bad
guys", but as giving a clear explanation of what the problem is, so
implementers understand the problem, and the difficulty that
tolerating multiple instances of single-instance fields can create.

Barry, as participant

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 13:19:40 -0400

The next post with the example DKIM bypass exemplifies the point that 
it is about DKIM fitting into the system, not the other way around. 
The current text tries to too hard to pass the buck on other systems 
when in fact, hate to say it, its about DKIM faults not anyone else. 
This is especially the case when it states it knows that "many email 
implementations violates RFC5322" and thats simply not true.  This 
offends  developers quite frankly.

Lets stop rationalization and lets call it for what it is. This issue 
fell through the (Threat Analysis) crack.  If we realized it back in 
2005/206 during the TA work, I think it is pretty safe to say we would 
of closed this loop more above and beyond just simply saying "Requires 
RFC 5322 compliance"

IMO, it really has nothing to do with user experiences per se, 
although that might be the end result.  Many, if not most, existing 
systems do already check for valid 822, 2822/5322 messages, especially 
ones that are blatant as this double 5322.From issue. I'm sure even 
the better  ones missed this one.  But many systems also do 
corrections, like add a missing Date: (a violations) or even a To:. 
All that does is make sure things are "correct."   Other systems might 
not like having a missing Date for example.

The point is this is par for the course and DKIM should recognized it 
to fit into it, not for others to fit into DKIM.

--
HLS

Barry Leiba wrote:
>> started with a problem it ignored to address. �Either it was ignorant
>> or poor engineering.
> 
>> � (This can also be taken as a �demonstration that DKIM is not designed
>> � �to support author validation.)
> 
>> the bad guy figure it out. �No blaming anyone.
>

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 09:49:13 -0700

On 10/11/10 11:46 PM, Barry Leiba wrote:
> On Mon, Oct 11, 2010 at 4:44 PM, Jim Fenton<[email-masked]>  wrote:

Thanks for clarifying.

Dave, could you then update the diffs at 
http://dkim.org/specs/rfc4871-to-bis-diff.htm to show the diffs from -02 
to RFC 4871?  It would be nice to see all of the differences in one place.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 13:45:45 -0400

Barry,

The main gist is not that:

      "many email implementations violates RFC5322"

but that there exist (how much, we don't know) email implementations 
who do not check for "100% correct" RFC5322 messages.

So I agree when you say:

     And we're telling verifiers that when you add DKIM, that
     tolerance might now be unwise.

but as shown in my example DKIM bypass:

    http://mipassoc.org/pipermail/ietf-dkim/2010q4/014802.html

The receiver already did have a valid RFC 5322 checker and it held the 
faulty message for approval.

If however, the faulty message was signed by my system and 
resubmitted, the mipassoc.org list will have accepted it.

Thats a DKIM implementation related issue perhaps but the text should 
indicate it needs to check for this stuff as well.  Not pass it on to 
other layers and expect the best outcome.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 11:21:51 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, October 12, 2010 8:48 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
> 
> Hector says...

Indeed, the advancement from PS to DS is the perfect time to tighten up requirements.  It's not any kind of re-engineering.

> tolerance might now be unwise.

Concur here as well.  "Be liberal in what you accept, be strict in what you send" has some very clear intent behind it.

> statement in there.  I'd like to see some consensus about whether to

Also +0.

> -1; I like the wording that's there.

Concur; -1 on the change.  I furthermore submit that we are compelled to describe the known "attack", as that's precisely what we are supposed to include in Security Considerations.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 Oct 2010 12:01:20 -0700

> Concur; -1 on the change.  I furthermore submit that we are compelled to describe the known "attack", as that's precisely what we are supposed to include in Security Considerations.

We should keep in mind that DKIM's job is to deliver a validated domain name.  I 
believe none of the "attacks" that have been discussed have anything to do with 
that task.  Instead, they pertain to other forms of attack on perceived message 
content validity, which is entirely outside of DKIM's scope.

Seriously.

d/
-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 15:29:46 -0400

> Concur here as well.  "Be liberal in what you accept, be strict in what you send" has some very clear intent behind it.

I don't see how this applies because its about being less tolerant.

See below.

> Concur; -1 on the change.  I furthermore submit that we are compelled to describe the known "attack", as that's precisely what we are supposed to include in Security Considerations.

Sure, but only when you work out all the security issues and due to 
time and the rush to rubber stamp this bis, it hasn't completely been 
done.

The text statement is not complete because the issue is not only when 
mail is not compliant but when a receiver system is indeed compliant 
but not by DKIM.  Only one solution was provided.

I showed this in the message:

indicating how ready systems can be RFC5322 checking ready but somehow 
with DKIM this is bypassed.

Only DKIM can check for DKIM requirements and this is not stated in 
the text.

There is no verifier statement.  (Note to those who have written me 
off list about the lack of verifier statement; please just don't tell 
just me - post your opinion here too!)

The TEXT should include something like:

      A verifier can be resistant to these exploits by invalidating
      messages with multiple From: header violations.

The current text is a first good effort, got lost on blaming others, 
but itself for lack of proper verifying its messages.

Why?

Because if this was discovered during the WG TA efforts, rest assured 
we would have the 5322.From Exception Trapping Logic added to the 
verification and signing logic.

Add it correctly so we can be done with this please.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 Oct 2010 16:41:18 -0400

>content validity, which is entirely outside of DKIM's scope.

-1. Seriously.

DKIM also attempts to provide assurance that content is unmodified. Without that the identity assurance is meaningless.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Oct 2010 15:12:10 -0700

On 10/12/10 12:01 PM, Dave CROCKER wrote:
> >... I furthermore submit that we are
> > compelled to describe the known "attack", as that's precisely what
> > we are supposed to include in Security Considerations.
>
>  We should keep in mind that DKIM's job is to deliver a validated
>  domain name. I believe none of the "attacks" that have been
>  discussed have anything to do with that task. Instead, they pertain
>  to other forms of attack on perceived message content validity, which
>  is entirely outside of DKIM's scope.

Disagree.  DKIM is to provide an authenticated domain _associated_ with 
message content, since the DKIM signature is _not_ visible to 
recipients.  As such, only the From header field is _required_ to be 
covered by the DKIM signature and is used to select which signature is 
to be verified.  While DKIM does not make any assertions of content 
validity, it offers a strong association between the From header field 
and the DKIM signature!  As such, it is of paramount importance that 
spoofed header fields affect the disposition of the message.

It is unfortunate the base specification failed to stipulate message 
rejection whenever singular header fields are found pre-pended to a 
signed message where these are fields illegally redundant, and yet 
likely displayed instead of the signed header fields actually associated 
with the DKIM signature.  Declaring the signature to be invalid when 
policy is often lacking is unlikely to represent a reasonable status 
able to properly control the disposition of the message.

As such, the added paragraph describing the attack falls short of 
offering an appropriate remedy.

Here is alternative text:

,---
For example, a message with multiple From: header fields violates
Section 3.6 of [RFC5322].  With the intent of providing a better user
experience, many agents tolerate these violations and deliver the
message anyway.  An MUA then might elect to render to the user the
value of the last, or "top", From: field.  This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result. A pre-pended From header
field above one signed is an indication of likely malicious intent,
where the message SHOULD be refused.

A signer wishing to be resistant to this specific attack can include
in the signed header field list an additional instance of each field
that was present at signing.  For example, a proper message with one
From: field could be signed using "h=From:From:..."  Because of the
way header fields are canonicalized for input to the hash function,
this would prevent additional fields from being added, after signing,
as this would render the signature invalid.
'---

There is no reason to suggest a strong association of the From header 
field with the DKIM signature is somehow diminished by the protocol not 
authenticating the From header field separately.  It is important to 
_refuse_ messages when a From header field is likely to be confused with 
an attempt to spoof the recipient.  If this means setting back progress 
of RFC advancement, retentions of the desired protections will make any 
delay well worth it.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 17:28:54 -0700

On 10/12/10 11:21 AM, Murray S. Kucherawy wrote:
> (Barry Leiba said:)

I'm somewhere in the middle; I don't agree with Hector and I don't like 
the wording that's there either.

Let's consider what a Bad Actor might try to do and what the result 
might be.

Suppose that a Bad Actor successfully inserted a second From header 
field in such a way that the user's MUA displayed it in place of the 
original, signed, From header field.

If the added From header field is from a different domain than the SDID, 
then the advice in section 6.3 paragraph 5 applies: "If the SDID is not 
the same as the address in the From: header field, the mail system 
SHOULD take pains to ensure that the actual SDID is clear to the 
reader." (I'm seeing a problem with this wording now too, but I 
digress.)  Presumably this applies to whatever From header field is 
going to be displayed.

If the added From header field is from the same domain as the SDID, 
there's a different problem.  Perhaps the message had an Author 
Signature and the attacker intended to masquerade as a different user in 
that domain.   But since we don't use the local part to establish what 
is and isn't an Author Signature (i.e., we don't look at the local part 
of i=) that's not a problem that DKIM is designed to address.

The problem isn't limited to From, I suspect.  One attack that we had 
considered early on was the modification of Subject, since it is 
prominently displayed to the user.  We don't require signing of Subject, 
but it is recommended in section 5.5.  Suppose an attacker adds an 
additional Subject header field, like:

Subject: Buy fake watches at fakewatch.example.com!

Will some clients display the second subject line?  I suspect some 
will.  Do we need to recommend that signers also add a protective second 
subject: to their h= value?  Or do we need to require that verifiers 
make sure that any header fields that are signed and aren't supposed to 
be duplicated, aren't?  I'm not sure, but right now I'm leaning toward 
the latter.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Oct 2010 21:05:08 -0400

Sounds like you agree with me. :)

Its incomplete security analysis and if you going to touch base with 
it regarding one attack method you need to take about the others, like 
I shown here:

This shows its not only a matter of bad messages, but also bypassing 
existing RFC 5322 checking.

Is this not important?

It clearly shows that DKIM needs to check its own DKIM requirements 
and not rely on other layer.

Verification is not even mentioned in this new section.

Why not?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 19:58:57 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Tuesday, October 12, 2010 5:29 PM

Doesn't the text added to Section 5.3, which ends with "a verifier SHOULD NOT validate a message that is not conformant", and the text added as Section 8.14, make it clear that some agents forgive such malformations with detrimental side effects, especially in MUAs, and thus admonish verifiers not to validate such messages?  I'm not clear on what you're saying is missing here.

Section 5.3's new text warns everyone, but especially verifiers, to check for these abnormalities.  Section 8.14 goes into detail about the issue, and provides signers with a mechanism for guarding against it in case there are verifiers that are not so careful.  So it seems to be both ends are addressed by the proposed text.

I think the case you reference as "latter" here is actually the enforcement of RFC5322 validity, and I agree that this should be done by anything that handles the message.

You're right, it's not limited to From:, but 8.14 only uses that as an example.  It does also contain a more general description of the issue.

If the diff from RFC4871 doesn't say the right thing, can you propose alternate text?

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 21:47:46 -0700

> Doesn't the text added to Section 5.3, which ends with "a verifier SHOULD NOT validate a message that is not conformant", and the text added as Section 8.14, make it clear that some agents forgive…

I had trouble understanding that paragraph.  I couldn't parse the first 
sentence at all.  Then I got distracted by the mixed use of "compliant" 
and "conformant" and tried to guess whether those were the same thing.  
So I wasn't paying attention to this.  I'll be sending out a last call 
response in a little while, and those comments are included there.

> Section 5.3's new text warns everyone, but especially verifiers, to check for these abnormalities.  Section 8.14 goes into detail about the issue, and provides signers with a mechanism for guarding…

As you point out, both 5.3 and 8.14 address this issue, but they're in 
separate places in the document. 8.14 refers to 5.2 and says that "DKIM 
processing is predicated on a valid email message" which, yes, says that 
signature verification should fail, but IMO not nearly clearly enough.  
Instead 8.14 goes into detail about how to force verification to fail if 
a duplicate header field is inserted (which is also covered in the 
description of h= in section 3.5).

The attack doesn't really have anything to do with the fact that the 
 From header field must be signed; the attack can be done on any signed 
header field that must be unique.

> You're right, it's not limited to From:, but 8.14 only uses that as an example.  It does also contain a more general description of the issue.

I missed the "for example" at the beginning of the paragraph.  It's easy 
to jump to the conclusion that From is the only special case because 
it's the only header field required to be signed.

> If the diff from RFC4871 doesn't say the right thing, can you propose alternate text?

I'll write something tomorrow.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 22:02:02 -0700

> Sent: Tuesday, October 12, 2010 9:48 PM

As Dave mentioned, a small block of words were accidentally omitted which does make it look strange.  I think he posted what was supposed to be there.

The mixed use of words is a fair complaint.  I think we can safely just switch one of those to the other one to make it consistent.

> Instead 8.14 goes into detail about how to force verification to fail
> if a duplicate header field is inserted (which is also covered in the

That was intentional, inasmuch as Section 5 contains normative stuff while 8.14 describes the "attack" in detail and then talks about how one might mitigate it if the enforcement of standard mail format can't be achieved at one end or the other.  The partitioning into definition (what you have to do to be compliant) and discussion (what you could do when compliance might not be possible) seemed to make sense there.

> header field that must be unique.

Quite right.  We could mention exactly that in 8.14 as well, just to make it explicit.

Thanks,
-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 01:17:32 -0400

> The mixed use of words is a fair complaint.  I think we can safely just switch one of those to the other one to make it consistent.

gad.  you guys have no literary sensibility at all.  sigh.

a shame this is a spec, which makes you guys right and the current text confusing.

sigh.
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 13 Oct 2010 15:04:56 -0000

>be duplicated, aren't?  I'm not sure, but right now I'm leaning toward 

I went through pretty much the same thought process and came to the
same conclusion.

It seems to me that there are some fairly cheap extra checks tht a
verifier can make that will defend against malformed mail that would
be likely to display confusingly in an MUA.  Yes, it's technically not
DKIM's job to verifiy 5322 conformance of incoming mail, but as Barry
noted, it's not anyone else's job, either.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 10:13:43 -0700

> noted, it's not anyone else's job, either.

My inclination is that the spec should say something like:

- The verifier SHOULD consider the signature invalid if a signed header 
field occurs an inappropriate number of times in the message header 
according to section 3.6 of RFC 5322.
- The verifier MAY consider the signature invalid if it detects other 
message syntax violations of RFC 5322.
- (??) The verifier SHOULD consider the signature invalid if the List-Id 
header field is signed and occurs more than once in violation of RFC 2919.

The last provision worries me a bit because it opens the door to other 
specifications that define header fields. On the other hand, I can 
picture an attack involving insertion of a bogus List-Id header field in 
order to influence the handling of the message.

The overall philosophy here is to strongly encourage verifiers to watch 
for this attack while not making current DKIM implementations obsolete, 
but without requiring essentially open-ended syntax checking of message 
by DKIM verifiers.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:47:59 +0100

> that is not compliant with RFC5322," near the end of 5.3.

Which is a start, but not nearly enough.

> 2. The addition of 8.14.

Which also is a start, but not nearly enough.

For the record, I am totall OPPOSED to this WGLC unless and until there is  
adequate normative wording to cover these loopholes (and the current  
change to 5.3 is not "adequate").

-- 
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, 13 Oct 2010 17:53:39 +0100

On Tue, 12 Oct 2010 14:00:19 +0100, Dave CROCKER <[email-masked]> wrote:

>>                compliant with those specifications prior to processing.

But that wording is clearly aimed at MTAs which claim to "improve"  
messages passed through them, which is not the problem raised by the scams  
under discussion. Moreover, it needs to be clear that both signers and  
verifiers need to take action on this, and in the case of verifiers it  
needs to be a MUST.

OTOH, it is not necessary to require a full 100% 5322/2045 compliance  
check. A header count of the headers mentioned in the "h=" tag should  
suffice. I suggested a suitable wording over a week ago.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:58:14 +0100

On Tue, 12 Oct 2010 21:41:18 +0100, Scott Kitterman  
<[email-masked]> wrote:

> DKIM also attempts to provide assurance that content is unmodified.  
> Without that the identity assurance is meaningless.

+1

And also assurance that other headers than From are unmodified.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 10:47:41 -0700

> Sent: Wednesday, October 13, 2010 10:14 AM

Does it make sense to be weaker about other things we haven't anticipated yet that might actually be worse?

5.3 covers everything by requiring general compliance; 8.14 points out the specific header-centric issue.  Since the normative part of 5.3 says SHOULD, I think this covers it nicely.

> order to influence the handling of the message.

I agree; I'd rather leave it at the above two.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Oct 2010 17:56:08 +0100

+1

Even though I might not agree with all of Hector's suggested rewordings.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 15:22:07 -0700

On 10/12/10 7:58 PM, Murray S. Kucherawy wrote:
> You're right, it's not limited to From:, but 8.14 only uses that as an 
> example. It does also contain a more general description of the issue.

Here's some text I propose for section 8.14, in place of the current 
text. Bear in mind that this is in the context of the Security 
Considerations section of the spec, so it is really a discussion of the 
threat and how it is dealt with, rather than normative text.

I went back and looked at the corrected text Dave Crocker sent for 
section 5.3.  Most of this is good advice, but section 5.3 is in the 
context of section 5, "Signer Actions", and is therefore the wrong place 
to add normative language for verifiers.  So I have added a new section 
6.1.1 that adds the requirement for message syntax checking to 
verifiers.  I'm open to suggestions on the strength of the verification 
requirement; I made it a SHOULD, but perhaps it should be a MUST.  I'm 
reluctant, however, to point at three sizable specifications and say 
that the verifier MUST check everything; that sounds like an 
unverifiable requirement.  I'm open to ideas.
=====

Many email implementations do not strictly enforce the message syntax 
specified in [RFC5322]. One potentially exploitable consequence of this 
is that an attacker who is capable of modifying a message in transit 
could insert additional header fields that, if properly placed, could be 
rendered to the recipient in preference to the originally signed header 
fields.

According to [RFC5322] section 3.6, certain header fields, including 
 From and Subject, MUST appear a maximum of once per message.  It is 
therefore possible for a verifier to detect the insertion and as 
discussed in Section 6.1.2, DKIM verifiers are expected to return a 
verification failure when the invalid insertion of signed header fields 
occurs.

Multiple occurrences of other header fields are not similarly 
constrained.  Should the signer wish to render a signature invalid if a 
particular header field is added, the signer has the option of listing 
the name of that header field (or an additional instance of it) in the 
h= value as discussed in Section 3.5.
=====
Suggested update to paragraph 2 of section 5.3:

Similarly, a message not compliant with [RFC5322], [RFC2045], and 
[RFC2047] can be subject to attempts by intermediaries to correct or 
interpret such content. See the Section 8 of [RFC4409] for examples of 
changes that are commonly made. Such "corrections" may break DKIM 
signatures or have other undesirable effects. Therefore, a DKIM signer 
SHOULD confirm that a message is compliant with those specifications 
prior to processing. </t>
=====

Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):

6.1.1 Validate the Message Syntax

The verifier SHOULD meticulously validate the format of the message 
being verified against the requirements specified in [RFC5322], 
[RFC2045], and [RFC2047].  In particular, limitations on the number of 
occurrences of particular header fields specified in [RFC5322] section 
3.6 SHOULD be verified. Messages found to be in violation of these 
checks MUST return a PERMFAIL (message syntax error) verification result.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Oct 2010 19:06:35 -0400

+1.

Barry, as the original issue submitter and I only provided suggested 
text to jump start WG input with better text, I am very happy with Jim 
Fenton's text.  It doesn't lay blame and straight to the key points.

Folks, this is really a simple solution and in my opinion, DKIM can 
gain from this issue resolution with a powerful new marketing angle in 
how DKIM raises the bar for Email Compliancy to further protect 
against current spoofing and phishing of user mail agents than any 
other email technology since the annals of electronic mail.

This is something that I can add to my technical marketing of DKIM for 
our customers. It provides a "payoff"  for customers to support DKIM 
and to upgrade their software to further harden it.

A win win for all.

Thanks Jim for stepping in and providing excellent text I hope 
everyone can compromise and agree with.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2010 16:32:42 -0700

> From: Jim Fenton [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2010 3:22 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> [...]

It seems to me you're saying the same thing bis-02 is saying, but with perhaps less terse language.  In particular, bis-02 says "SHOULD NOT validate" something that's malformed, while you're saying "SHOULD" validate format before processing.  Those sound the same to me, but if people like this expression of it better then I'm also happy with it.

You're right about splitting the verifier advice out to Section 6.  Good point.  And your rewrite of 8.14 is cleaner than what we have now.

I agree that using a MUST is too strong; not only is it a very hard requirement to achieve but it wanders into the realm of making DKIM modules responsible for 5322 enforcement, and I don't like that at all.  Thus I think SHOULD is appropriate, and MAY is even more so (but I'll settle for the former).

A minor point: I would like your proposed 5.3 and 6.1.1 (should that be 6.1.2?) text to contain something like "See Section 8.14 for further discussion."

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Oct 2010 20:25:55 -0700

> It seems to me you're saying the same thing bis-02 is saying, but with perhaps less terse language.  In particular, bis-02 says "SHOULD NOT validate" something that's malformed, while you're saying…

Correct; I had problems with the wording and organization but not the 
intent.

> A minor point: I would like your proposed 5.3 and 6.1.1 (should that be 6.1.2?) text to contain something like "See Section 8.14 for further discussion."

I'm fine with that.  You may have picked up an inconsistency in section 
numbers between 6.1.1 and 6.1.2 because I was having trouble deciding 
whether to put this new section before or after the existing 6.1.1.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Oct 2010 18:41:54 +0200

> checks MUST return a PERMFAIL (message syntax error) verification result.

-1

If we go for changing the protocol in order to avoid the exploit, we 
should explicitly enumerate the header fields whose duplication 
verifiers MUST check.  "SHOULD meticulously validate" + "MUST return 
PERMFAIL" make for a fuzzy protocol.

The spec should also state whether duplicated fields invalidate a 
signature even when they are duly signed.  Finally, it does make sense 
to duplicate fields in h= as stated in -02's 8.14, because that's the 
only way to guard against the exploit in case the destination's 
verifier is coded according to the previous protocol version.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Oct 2010 18:49:07 +0200

> statement in there.  I'd like to see some consensus about whether to

+1 for leaving it, it is just distracting in that context.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:34:58 -0400

> +1 for leaving it, it is just distracting in that context.

Clarifying an error I made in the original message:  it should say
"I'd like to see some consensus about whether to REMOVE it or keep
it."  And it looks like Alessandro is on the side of removing
("leaving") it.

Sorry for the confusing typo.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Oct 2010 14:40:14 -0400

> PERMFAIL" make for a fuzzy protocol.

I think this is clear in Jim's text, and not contradictory or fuzzy at
all.  They SHOULD check.  If they check and the message violates the
checks, they MUST return a PERMFAIL.  Where's the contradiction or
confusion?

Is this, perhaps, an issue that's confusing to non-native English
speakers?  If so, we should make sure we take that into account in how
we phrase it.

> signature even when they are duly signed.

It does.  A message that has two "From" lines, for example, is in
violation of RFC 5322.  It makes no difference whether it's signed or
not.  RFC 5322 (and the other specs) doesn't know about the signature
and doesn't care, and anything that checks compliance with it doesn't
care either.

Barry, as participant

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Oct 2010 11:12:51 +0200

> checks, they MUST return a PERMFAIL.  Where's the contradiction or

Fuzziness stems from the fact that a signature on a given message may 
either verify or not depending on how meticulously the verifier 
interprets that "SHOULD".  The "MUST" immediately following it is 
deceptive because it conveys the false impression that a signature is 
REQUIRED to fail in case a particular header field is added after signing.

Because of the SHOULD, existing verifiers can still be considered 
compliant.  Thus, it may still make sense for a signer to still put 
"h=from:from".  Why did Jim remove that advice?

> and doesn't care, and anything that checks compliance with it doesn't

MUAs often disallow writing a "From" with multiple mailboxes, thus a 
sender may happen to end up with two "From" fields after hacking in an 
attempt to recognize authorship to a second mailbox.  The reason why 
such a message may be questioned is not relevant to the signature 
validation algorithm.  Contrast that with

   Signatures MAY be considered invalid if the verification time
   at the verifier is past the expiration date.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:06:17 +0100

> header field is signed and occurs more than once in violation of RFC  

I think the first SHOULD needs to be a MUST (especially as it is a fairly
simple test to implement).

The MAY is fine.

The second SHOULD is fine, except that it should be a blanket coverage of
all other standards that define header fields limited to one occurrence.
We can't expect implementers to keep up-to-date with EVERY such standard,
but they should try to do as much as they can. If SHOULD is too strong for
that sort of approach, then I would make it a MAY with an "encouragement"
do you as much as they can. Obvious candidates are the List-* headers and
RFC204[56].
> order to influence the handling of the message.

See above.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 15 Oct 2010 14:06:16 +0100

> threat and how it is dealt with, rather than normative text.

OK, we're gradually moving towards an acceptable text, but we're not there
yet.
>
> ... Most of this is good advice, but section 5.3 is in the
> 6.1.1 ...

+1

> rendered to the recipient in preference to the originally signed header

I don't quite see what an attacker can usefully do by modifying messages
in transit. If they message was already signed (say by ebay), then the
attacker must somehow get ebay to sign a message with a useful (to him)
text in its body. So what is the benefit to him of making it appear From:
someone who is not Ebay (except maybe to ensure that replies get sent to
him - since I assume that MUAs that only display the first header will
also Reply-To that header)?

So I think there is a wide range of possible attacks involving duplicated
headers, and the text needs to be general enough to cover them.
>
> According to [RFC5322] ... signed header fields
> occurs.
>
> Multiple occurrences ... as discussed in Section 3.5.

+1

> checks MUST return a PERMFAIL (message syntax error) verification result.

I have a problem with "meticulously validate". That is so hard to do that
most implepemters will take advantage of that "SHOULD" and omit the tests.
Much better to specify a less meticulous validation (header counting for
example) and then elevate that "SHOULD" to a "MUST".

Here is an alternative text that I published on Oct 6th (and on which
nobody commented). It is intended to go in section 6.1.1, presumably after
the paragraph beginning "If the "h=" tag ...":

"If the "h=" tag includes any header field for which, according to
[RFC5322], the maximum number within the header section is limited to 1,
and if more than 1 occurrence of that header field is present in the
message, the verifier MUST ignore the DKIM-Signature header field and
return PERMFAIL (multiple occurrences of XXX header field). Moreover, it
SHOULD so treat any header field defined in any other standards track
document to have a maximum occurrence of 1."

If you think that is a bit too vicious, here is a slightly more
permnissive version:

"If the "h=" tag includes any header field for which, according to
[RFC5322], the maximum number within the header section is limited to 1,
and if the number of occurrences of that header field present in the
message exceeds its number of occurrences in the "h=" tag, ......".

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 15 Oct 2010 10:04:40 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Friday, October 15, 2010 9:06 AM
> To: DKIM

The particular danger that comes to my mind would be where the signing
domain uses l= (yes, I know there is a warning against doing this....
why don't we just deprecate "l="?). If evil ne'er-do-well can get a
short, somewhat generic signed email from a low level person at an
organization then they can potentially leverage this with the multiple
headers to generate a spear phishing attack. I have not trod to far down
this path to construct a proof of concept but a google for DKIM + l=
yielded examples (Assuming you are willing to wade through a bunch of
results) of domains using "l=", most likely out of ignorance (a fertile
breeding ground for abuse).

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 Oct 2010 10:13:26 -0400

On Friday, October 15, 2010 10:04:40 am MH Michael Hammer (5304) wrote:
> why don't we just deprecate "l="?

Yes.  Please.

Scott K

---

From: John Levine <[email-masked]>
Date: 15 Oct 2010 15:13:35 -0000

>> why don't we just deprecate "l="?

Agreed.  Has anyone ever found it useful for its nominal purpose of
messages transiting MLMs?

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 15 Oct 2010 15:48:05 +0100

> also Reply-To that header)?

You've answered your own question here. Given that a successful phisher 
would have access to my Sent Messages mailbox

> headers, and the text needs to be general enough to cover them.

Here's a more interesting attack:

Compose an email apparently from eBay, and send it to yourself. Get a valid 
DKIM signature, then add a From: header containing an eBay address, and use 
the replay to send that message to third parties.  Now, your email will be 
displayed to (some) recipients as an authenticated email from eBay. Note, 
the problem is that the MUA is saying the message is Authenticated, but the 
user is doing reputation assignment based on the (incorrectly) displayed 
eBay address.

Actually, I'm not sure this is different from just sending email with a 
spoofed From: header, though the dual header attack might be more useful to 
a phisher who has access to a system which, for example, won't sign spoofed 
headers.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Oct 2010 18:29:09 +0200

On 15/Oct/10 17:13, John Levine wrote:
> In article<[email-masked]>  you write:

For me, it works as advertised:  I can verify my own messages when 
they come back from a list that just adds footers.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Oct 2010 09:47:24 -0700

On 10/15/10 6:06 AM, Charles Lindsey wrote:
> On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton<[email-masked]>  wrote:
>

An attacker could compose a message from some other domain with a good 
reputation, and add a From header indicating it's really authored by 
someone at a different domain (say by ebay). Even if ebay has an ADSP 
record, it's possible that the invisible (originally)  From address 
would be used to in the author signature check, which would pass.

I'm also concerned about other header fields, like Subject, where a 
one-line spam could be substituted as the visible subject line for a 
signed message.

> headers, and the text needs to be general enough to cover them.

Agree.

> example) and then elevate that "SHOULD" to a "MUST".

We can drop the "meticulously" part.  It was put there for consistency 
with the validation of the signature header field (current section 
6.1.1) but I agree, probably isn't a practical requirement.

> message exceeds its number of occurrences in the "h=" tag, ......".

The header field limitations are more complex than that (see 
Resent-Sender). I prefer to more simply refer to the appropriate section 
of RFC 5322 and say that it must be adhered to.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Oct 2010 09:52:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, October 15, 2010 2:13 AM
> To: Barry Leiba

It's a specific example of a more general statement, and the general statement is still there in what Jim said.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Oct 2010 09:59:40 -0700

> "h=from:from".  Why did Jim remove that advice?

I wanted it to be clear that it's the verifier's job to detect the 
duplication, not the signer's job to work around the problem.  Recall 
that SHOULD means, roughly "Do it unless you have a valid reason not to, 
and have considered the implications."

Besides, as Mark Delany said yesterday, having to do

h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id

"strikes me as an ugly hack."

> attempt to recognize authorship to a second mailbox.

Are you saying that there are MUAs that disallow a From: with multiple 
addresses, but support the addition of multiple From: header fields?  If 
so, I hope it's not a popular MUA that's doing this.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Oct 2010 20:07:19 +0200

> and have considered the implications."

The implications are that instead of having a signature that is either 
valid or not we'll have signatures that verify according to a variable 
percentage of existing verifiers, as it is for virus detection.

Why not mandate to fail verification if the signed body contains a virus?

To clarify, I'm not against changing DKIM.  However, if we do, we 
better integrate the change in the original design.  First of all, it 
should be in section 5.4. Second, it has to be an explicit list of 
header fields, rather than generic references to RFC 5322, RFC 2919, 
etcetera.  Third, the spec should state that any repetition of such 
fields in the h tag, e.g. h=from:to:from:to, has to be regarded as a 
backward compatible guard, and new implementations must discard 
duplicated names retaining their first occurrence only.  Then, it can 
derive the implication that signers cannot produce a valid signature 
of a message whose header actually contains multiple instances of any 
listed field... Lots of work and some semantic change...

> "strikes me as an ugly hack."

But then the whole DKIM-Signature is an ugly hack :-)

> so, I hope it's not a popular MUA that's doing this.

One can always find ways or extensions to add /any/ header field more 
easily than for modifying existing ones.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:15:20 +0100

> user is doing reputation assignment based on the (incorrectly) displayed

Yes, that is more like the attacks that I have been worrying about. But I
don't see what you gain by be "sending it to yourself". Is that supposed
to cause it to pick up some signature on the way? If so, then it certainly
won't pick up an ebay signature (though it might be a useful technique if
it was Yahoo rather than Ebay you sere trying to attack).

But yes, getting a valid signature on it (even the phisher's own
signature) is sufficient to prevent any ADSP lookup happening, and the
main aim is to avoid getting caught by ebay's 'discardable'.

> a phisher who has access to a system which, for example, won't sign  

I would think any competent phisher can find a system to generate whatever
he want to generate. But a simple (unsigned) message with a spoofed From:
header will get trapped by an ADSP 'discardable' (modulo the problem that
ADSP doesn't actually specify which of several From: headers to look at,
though most ADSP implementations will likely just look at the first).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 18 Oct 2010 12:15:48 +0100

> would be used to in the author signature check, which would pass.

Exactly so, but that does not involve any "modifying messages in transit",
and people seem to be fixated on "modifying in transit" and on "replay
attacks", whereas the nastiest scams do not, AFAICS, involve either of
those. That was why I asked the question, and I have not seen a really
satisfactory answer to it yet.