-----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 9:48 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
I had trouble understanding that paragraph. I couldn't parse the first
sentence at all. Then I got distracted by the mixed use of "compliant"
and "conformant" and tried to guess whether those were the same thing.
So I wasn't paying attention to this. I'll be sending out a last call
response in a little while, and those comments are included there.
As Dave mentioned, a small block of words were accidentally omitted which does
make it look strange. I think he posted what was supposed to be there.
The mixed use of words is a fair complaint. I think we can safely just switch
one of those to the other one to make it consistent.
As you point out, both 5.3 and 8.14 address this issue, but they're in
separate places in the document. 8.14 refers to 5.2 and says that "DKIM
processing is predicated on a valid email message" which, yes, says that
signature verification should fail, but IMO not nearly clearly enough.
Instead 8.14 goes into detail about how to force verification to fail
if a duplicate header field is inserted (which is also covered in the
description of h= in section 3.5).
That was intentional, inasmuch as Section 5 contains normative stuff while 8.14
describes the "attack" in detail and then talks about how one might mitigate it
if the enforcement of standard mail format can't be achieved at one end or the
other. The partitioning into definition (what you have to do to be compliant)
and discussion (what you could do when compliance might not be possible) seemed
to make sense there.
The attack doesn't really have anything to do with the fact that the
From header field must be signed; the attack can be done on any signed
header field that must be unique.
Quite right. We could mention exactly that in 8.14 as well, just to make it
explicit.
Thanks,
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html