Subject: [ietf-dkim] Ticket #24

From: Douglas Otis <[email-masked]>
Date: Fri, 06 May 2011 09:56:23 -0700

The intended content of this ticket by Charles Lindsey, Rolf Sonneveld 
and my self is as follows:
,---
We were asked by Barry to provide an agreed text to resolve the
"multiple header" problem, for consideration by the WG.

The attack arises when some header (typically From:) which is supposed
to appear once in fact appears twice. DKIM is REQUIRED to sign the
bottom one, whereas most email agents will only display or use the top
one. There are three forms of the attack:

1. Some man-in-the-middle adds a header to some already signed message.
2. An earlier validly signed message is replayed with an added header.
3. The message is signed by the Bad Guy himself
(d="my-throwayay-domain.com") with two headers, of which he hopes the
recipient will see only the top (unsigned) one.

The proposed technique of signing with 'h="from:from"' works fine in the
first two cases (where the signer can be presumed honest) but fails
totally when this technique is not used by a "to big to block"
domain and in the third where he most certainly is not honest.

We are concerned that all who see a validly signed message which appears
to be From: [email-masked] will be able to *rely* on what
they see, whether they understand DKIM, or whether they have just been
told that their ISP does some magical trick to "detect people
masquerading as Ebay".

DKIM can not limit its validation to process to just signature
confirmations. This approach would then expect existing email agents to
adopt DKIM's unusual header selection methods retro-actively. To be
compatible with existing email infrastructure and transparent to the
fullest extent possible, one can not expect new supporting
infrastructure or modified clients; This can *only* be achieved by some
mandatory test within the Verifier.

We propose two wordings; one which tests for all once-only headers, and
a less desirable minimalistic version just testing for a duplicate From:
(which would be the cause of the worst scams, though lesser attacks
involving other headers have been mentioned on the WG.

1. Add:
---
6.1.n.  Validate Multiple Header Field Occurrences

Through inadvertence or malice, a message may be received having
multiple occurrences of single only header fields per [RFC5322]. To
provide results upon which subsequent agents can rely, verifiers MUST
detect an invalid number of single only header fields present within the
Signature header field's "h=" list and return PERMFAIL (illegal multiple
header fields).

See Sections 8.14 and 8.15 for further discussion of such attacks.

2, Add to 6.1:
---
To provide results upon which subsequent agents can rely, verifiers MUST
detect an invalid number of From header fields and return PERMFAIL
(illegal multiple headers.  [RFC5322] requires there be exactly one
 From header field.

See Sections 8.14 and 8.15 for further discussion of header field
considerations.
---

Editor's Note:
Wording within Sections 8.14 or 8.15 may need to change slightly to be
in alignment with these changes.

NOTE. We claim that these wordings make no layering violations. They
affect only operations required to be performed as part of the DKIM
protocol. The result reported by the verifier will still be just
PASS/PERMFAIL/TEMPFAIL, and whether or not the (malformed) message gets
forwarded to the recipient (possibly annotated with warnings) is a
matter for the Assessor, not for DKIM.
'---
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 14:05:11 -0400

I have just updated the tracker ticket for this:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

To be concise, here are the proposed changes.  The group's preferred

> See Sections 8.14 and 8.15 for further discussion of such attacks.

That asks for a lot, so the group has a second alternative, #2, which

> See Sections 8.14 and 8.15 for further discussion of header field

While I address the other two open tickets, do the IESG writeup, and
otherwise get ready to send 4871bis to the IESG, everyone please take
the time to read Doug's note and weigh in on these two alternatives.
Let us know, in this thread, whether you support one or the other of
them, or whether you prefer the text as it currently is in the -09
version of 4871bis.

If you have anything to say in argument for or against, please keep it
VERY BRIEF.  This is a call for new consensus, and the arguments have
been made at length already.  We need to see rough consensus *for* one
of these changes in order to make them.

I'll let this float for a few days -- I expect to be ready with the
writeup by the middle of next week.

Barry, as chair

---

From: "John Levine" <[email-masked]>
Date: 6 May 2011 18:14:43 -0000

I appreciate the work that Doug and Charles put into their proposal,
but for reasons already discussed, I think we should leave section
6.1 as is in -09.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 11:21:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Friday, May 06, 2011 11:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Ticket #24
> 

+1.  Sections 3.8, 8.14 and 8.15 already say enough about this issue.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 May 2011 10:30:29 -0700

> but for reasons already discussed, I think we should leave section

+1

d/

-- 

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

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 10 May 2011 07:28:55 -0700

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 May 2011 23:37:48 -0400

> writeup by the middle of next week.

I have the writeup almost ready for the IESG, and this issue has had
enough responses for me to get a clear sense:
The existing text had consensus before, and there is not consensus to
change it now.  The existing text will stay.  I'm closing issue #24 as
"wontfix".

My thanks to Doug, Charles, and Rolf for working out text to support
their position, and thanks to the others for reviewing it and
commenting.

Barry, as chair