On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote: > Here’s my proposal for a section in Security Considerations to talk about the > malformation issues that have been discussed on the list. This is an > addition to -02 directly and does not continue from any of the other > proposals.
I like the sentiment, and the background up to here, but... > Because of this, DKIM implementers are strongly advised to apply one or more > of the following design decisions: > > 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. 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). > 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. > 3) For any header field listed in Section 3.6 of [MAIL] as having an upper > bound on the number of times it can appear, include the name of that field > one extra time in the “h=” portion of the signature to prevent addition of > fraudulent instances. Any attachment of such fields after signing would thus > invalidate the signature (see Section 3.5 and 5.4 for further discussion). This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem. 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." Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
