ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-24 23:58:15

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