On Oct 24, 2010, at 10:50 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Steve Atkins >> Sent: Sunday, October 24, 2010 10:36 PM >> To: IETF DKIM WG >> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues >> >> That still expands the API from the DKIM verifier quite a lot - it >> requires the verifier to explicitly list which headers are signed, and >> which aren't (that the h= field doesn't do that is what we're having >> problems with). It would also require that to be pushed all the way >> downstream to other pieces of software, perhaps via something similar >> to an extended Authentication-Results type of header. >> >> That's not impossible, but seems very complex for the specific problem >> we're considering - we just need to communicate "This message violated >> 5322, specifically in a way that makes us think the sender is trying to >> game DKIM" (either by flagging the mail as syntactically invalid and >> suspicious at some point in the mail stream, or invalidating the DKIM >> signature). >> [...] > > You seem to have some specific ideas in mind already. Can you propose some > alternate text?
Sure. Taking into account some of the other feedback too: --- 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, 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] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Because of this, inbound mail system implementors should consider defending against this sort of replay attack by either 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. Senders who feel that their messages might be particularly vulnerable to this sort of attack who don't want to rely on receiver filtering of invalid messages can ensure that adding additional headers will break their DKIM signature by including two copies of the headers they're concerned about in the signature (e.g. "h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further discussion. --- It's significantly less subtle than your phrasing, but I think bluntness and clarity win out for a security discussion. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
