On 10/12/10 7:58 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Jim Fenton >> Sent: Tuesday, October 12, 2010 5:29 PM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments >> >> 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. > 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.
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 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. 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. > 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. 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
