On Wed, Feb 16, 2011 at 3:52 PM, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> 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(_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.
+1
--
Jeff Macdonald
Ayer, MA
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html