On Oct 25, 2010, at 9:58 PM, Murray S. Kucherawy wrote:
8.14 Malformed Inputs
DKIM allows additional header fields to be added to a signed message without
breaking the signature. This tolerance can be abused, e.g. in a replay
attack, by adding additional instances of header fields that are displayed to
the end user or used as filtering input, such as From or Subject, to an
already signed message in a way that doesn't break the signature.
The resulting message violates section 3.6 of [MAIL]. The way such input
will be handled and displayed by an MUA is unpredictable, but in some cases
it will display the newly added header fields rather than those that are part
of the originally signed message alongside some “valid DKIM signature”
annotation. This might allow an attacker to replay a previously sent, signed
message with a different Subject, From or To field.
Because of this, DKIM implementers are strongly advised to reject or treat as
suspicious any message that has multiple copies of header fields that are
disallowed by section 3.6 of [MAIL], particularly those that are typically
displayed to end users (From, To, Cc, Subject). A signing module could
return an error rather than generate a signature; a verifying module might
return a syntax error code or arrange not to return a positive result even if
the signature technically validates.
Senders concerned that their messages might be particularly vulnerable to
this sort of attack and do not wish to rely on receiver filtering of invalid
messages can ensure that adding additional header fields will break the DKIM
signature by including two copies of the header fields about which they are
concerned in the signature (e.g. "h= ... from:from:to:to:subject:subject
...). See Sections 3.5 and 5.4 for further discussion of this mechanism.
Looks fine to me (other than some light wordsmithing of the final paragraph -
look like there's a "who" or "who are" missing).
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html