+1.
Barry, as the original issue submitter and I only provided suggested
text to jump start WG input with better text, I am very happy with Jim
Fenton's text. It doesn't lay blame and straight to the key points.
Folks, this is really a simple solution and in my opinion, DKIM can
gain from this issue resolution with a powerful new marketing angle in
how DKIM raises the bar for Email Compliancy to further protect
against current spoofing and phishing of user mail agents than any
other email technology since the annals of electronic mail.
This is something that I can add to my technical marketing of DKIM for
our customers. It provides a "payoff" for customers to support DKIM
and to upgrade their software to further harden it.
A win win for all.
Thanks Jim for stepping in and providing excellent text I hope
everyone can compromise and agree with.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Jim Fenton wrote:
On 10/12/10 7:58 PM, Murray S. Kucherawy wrote:
You're right, it's not limited to From:, but 8.14 only uses that as an
example. It does also contain a more general description of the issue.
If the diff from RFC4871 doesn't say the right thing, can you propose
alternate text?
Here's some text I propose for section 8.14, in place of the current
text. Bear in mind that this is in the context of the Security
Considerations section of the spec, so it is really a discussion of the
threat and how it is dealt with, rather than normative text.
I went back and looked at the corrected text Dave Crocker sent for
section 5.3. Most of this is good advice, but section 5.3 is in the
context of section 5, "Signer Actions", and is therefore the wrong place
to add normative language for verifiers. So I have added a new section
6.1.1 that adds the requirement for message syntax checking to
verifiers. I'm open to suggestions on the strength of the verification
requirement; I made it a SHOULD, but perhaps it should be a MUST. I'm
reluctant, however, to point at three sizable specifications and say
that the verifier MUST check everything; that sounds like an
unverifiable requirement. I'm open to ideas.
=====
8.14. Attacks Involving Addition of Header Fields
Many email implementations do not strictly enforce the message syntax
specified in [RFC5322]. One potentially exploitable consequence of this
is that an attacker who is capable of modifying a message in transit
could insert additional header fields that, if properly placed, could be
rendered to the recipient in preference to the originally signed header
fields.
According to [RFC5322] section 3.6, certain header fields, including
From and Subject, MUST appear a maximum of once per message. It is
therefore possible for a verifier to detect the insertion and as
discussed in Section 6.1.2, DKIM verifiers are expected to return a
verification failure when the invalid insertion of signed header fields
occurs.
Multiple occurrences of other header fields are not similarly
constrained. Should the signer wish to render a signature invalid if a
particular header field is added, the signer has the option of listing
the name of that header field (or an additional instance of it) in the
h= value as discussed in Section 3.5.
=====
Suggested update to paragraph 2 of section 5.3:
Similarly, a message not compliant with [RFC5322], [RFC2045], and
[RFC2047] can be subject to attempts by intermediaries to correct or
interpret such content. See the Section 8 of [RFC4409] for examples of
changes that are commonly made. Such "corrections" may break DKIM
signatures or have other undesirable effects. Therefore, a DKIM signer
SHOULD confirm that a message is compliant with those specifications
prior to processing. </t>
=====
Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):
6.1.1 Validate the Message Syntax
The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and [RFC2047]. In particular, limitations on the number of
occurrences of particular header fields specified in [RFC5322] section
3.6 SHOULD be verified. Messages found to be in violation of these
checks MUST return a PERMFAIL (message syntax error) verification result.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html