-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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 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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html