On Wednesday, February 16, 2011 03:52:24 pm Murray S. Kucherawy wrote: > This is the last text that I circulated on the bogus header matter, in > reply to Barry's proposed path to resolution. The group was pretty > exhausted from debate at that point so there was little response. > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Barry Leiba Sent: > > Monday, November 08, 2010 1:20 AM > > To: IETF DKIM WG > > Subject: [ietf-dkim] Getting resolution on the "double header" issue > > > > Proposal: > > > > 1. The DKIM spec is responsible for describing the problem in terms of > > how it relates to signed and unsigned versions of the fields. That's > > the stuff in 8.14. > > Concur. I worked through an 8.14 proposal a couple of weeks ago using > input from the list. The last text I have was: > > 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 who 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. > > Specific validity rules for all known header fields can be gleaned from the > IANA "Permanent Header Field Registry" and the reference documents it > identifies. > > > 2. The DKIM spec should probably say that signers need to sign valid > > messages, and, therefore, SHOULD NOT sign things like this. Text > > along the line of this might work well: > > "Signers SHOULD take reasonable steps to ensure > > that the messages they're signing are valid according to [RFC 5322, > > etc]." Leaving the definition of "reasonable" out allows flexibility. > > It may be waffly, but I like the approach in this case. > > Works for me. How about: > > 3.10. Input Requirements > > DKIM's design is predicated on valid input. Therefore, signers and > verifiers SHOULD take reasonable steps to ensure that the messages they > are processing are valid according to [MAIL], [MIME], and any other > relevant message format standards. See Section 8.14 for additional > discussion and references. > > > 3. It'd be reasonable for the DKIM spec to remind verifiers that > > signers aren't supposed to sign stuff like this, so they might > > consider that when deciding what to do with it after verification. > > It'd be reasonable to remind them of this particular case. But > > I think that all ought to be informative text. > > Yup; the above two amendments cover both cases.
+1. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
