On Wed, Feb 16, 2011 at 3:52 PM, Murray S. Kucherawy <[email protected]> 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 -- Jeff Macdonald Ayer, MA _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
