> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Steve Atkins > Sent: Sunday, October 24, 2010 9:54 PM > To: IETF DKIM WG > Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues > > > 1) During the handling of a message in conjunction with a DKIM result > > that indicates a valid signature, consider as valid only those fields > > and the body portion that was covered by the signature. Note that this > > is not to say unsigned content is not valid, but merely that the > > signature is making no statement about it. > > There are a couple of issues with this. First, it implies that if a > DKIM signature does cover a header, then that DKIM signature is saying > that that header is "valid", which isn't the case in general.
Ah right. Need to be meticulous here. How about: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not. Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it. > Second, this is nearly meaningless operationally. for the sort of > attack that's been envisioned (showing different author or subject in > an apparently signed message), as there's no real way to consider any > particular field as valid or invalid (unless you're communicating the > information all the way to the MUAs display code, or you're deleting > headers in transit - which are both possibilities, but ones that would > need to be called out explicitly). The text is intended to be generic, referring to any entity that might consume a DKIM "pass" result. The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically. > > 2) Refuse outright to sign or verify any message that is not > syntactically valid. > > This is overly strong, as a lot of messages that are not 5322 valid are > wanted (bare linefeeds, amongst other issues). Encouraging signers or > verifiers to deny the existence of a DKIM identity in those cases just > makes it harder to distinguish between wanted invalid mail and unwanted > invalid mail. This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting. If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically. > Something that's more to the point we're concerned about might be more > like "A mail system that considers DKIM signatures during mail delivery > should treat with suspicion any email that has multiple copies of any > header where RFC 5322 requires they have no more than one, as it may be > an attempt to replay a DKIM signed message with different content. DKIM > verifier implementors may consider messages that are malformed in this > way as unsigned." Maybe that can be some example-type text tacked on to the second bullet point? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
