[ietf-dkim] FW: Getting resolution on the "double header" issue
ietf-dkim at kitterman.com
Wed Feb 16 13:33:54 PST 2011
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: ietf-dkim-bounces at mipassoc.org
> > [mailto:ietf-dkim-bounces at mipassoc.org] 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
> 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
> > 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.
More information about the ietf-dkim