Issued in behalf of myself, Doug Otis and Rolf Sonneveld
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 in the third where he most certainly is not honest, and sometimes
in #1 and #2 if this technique is not used by a "too big to block" domain.
We are concerned that all who see a validly signed message which appears
to be From: somewhere(_at_)ebay(_dot_)com 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". This can *only* be achieved by some mandatory test
within the Verifier.
Moreover, DKIM can not limit its validation process to just pure 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;
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 any such single-only header field which has
been mentioned 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.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk 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