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: somewh...@ebay.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: c...@clerew.man.ac.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