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