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(_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.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html