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. > If the diff from RFC4871 doesn't say the right thing, can you propose > alternate text?
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. ===== 8.14. Attacks Involving Addition of Header Fields 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
