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
