-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Tuesday, October 12, 2010 5:29 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
The problem isn't limited to From, I suspect. One attack that we had
considered early on was the modification of Subject, since it is
prominently displayed to the user. We don't require signing of
Subject,
but it is recommended in section 5.5. Suppose an attacker adds an
additional Subject header field, like:
Subject: Buy fake watches at fakewatch.example.com!
Will some clients display the second subject line? I suspect some
will. Do we need to recommend that signers also add a protective
second
subject: to their h= value? Or do we need to require that verifiers
make sure that any header fields that are signed and aren't supposed to
be duplicated, aren't? I'm not sure, but right now I'm leaning toward
the latter.
Doesn't the text added to Section 5.3, which ends with "a verifier SHOULD NOT
validate a message that is not conformant", and the text added as Section 8.14,
make it clear that some agents forgive such malformations with detrimental side
effects, especially in MUAs, and thus admonish verifiers not to validate such
messages? I'm not clear on what you're saying is missing here.
Section 5.3's new text warns everyone, but especially verifiers, to check for
these abnormalities. Section 8.14 goes into detail about the issue, and
provides signers with a mechanism for guarding against it in case there are
verifiers that are not so careful. So it seems to be both ends are addressed
by the proposed text.
I think the case you reference as "latter" here is actually the enforcement of
RFC5322 validity, and I agree that this should be done by anything that handles
the message.
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?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html