My only comment is that we are making way too much out of this.
DKIM requires a From: hashing a minimum requirement and since RFC5322
only one there are two basic fundamentals rules, together called the
One From DKIM Rule:
One From DKIM Rule:
Verify - DKIM must only see one From when verifying. If multiple
From: headers are found, the message is automatically
invalid
from a valid DKIM signature standpoint.
Signing - DKIM must only see one From when signing. If multiple From:
headers are found, the message is automatically invalid for
a DKIM signature standpoint. In other words, it MUST NOT
continue and sign the message.
Dealing with Exploits:
For the most part, we are dealing with injection of addition From:
header(s) in an already signed message. DKIM implementations
following the One From DKIM Rule, will mitigate this problem.
The proposed h=from kludge, i.e. h=From:From:, has a single design
purpose to assist LEGACY DKIM implementations that are not up-to-par
with the One From DKIM Rule.
Some people don't like Kludges but they (DKIM signing operators) will
add it if they are consider of this and want to "help" legacy DKIM
verifiers. But others will give a hoot and erroneously assume that
ALL edges will deal with it.
What I found when I opened this issue using the fake "President Obama"
message from me
http://mipassoc.org/pipermail/ietf-dkim/2010q4/014680.html
was that the Dave's list server did indeed invalidate a RFC5322
message submission IFF the message was NOT signed.
However, the problem was if the submission was DKIM signed, the Dave's
list server/DKIM integrated implementation allowed the illegal
submission to continue - stripping, resigning and distribution to the
list members.
Anyway, I think the bottom line is that the modern DKIM specification
must make it clear about the "One From DKIM Rule" and as most systems
upgrade, they will eventually make this issue moot. Most likely, the
will use the knowledge to also update their edge software, if its not
already checking. But as pointed out above, the Dave software already
did check for valid RFC5322 submissions - the Loop Hole was his DKIM
integration allow it to bypass this protection already in place.
Therefore, that means, to me, the DKIM specification MUST make it
clear about a ONE FROM DKIM implementation as cited above.
--
Barry Leiba wrote:
I actually like Charles's edits except for one paragraph, and, as a
participant, would be happy to change 8.15 accordingly. The one
problem paragraph is this one:
On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:
...
Recall that, when multiple instances of a given header field are
present, they are signed starting with the last one and working
upwards (section 5.4.2). A variety of attacks taking advantage of
this feature can be envisaged. In some, the attacker is himself the
signer, signing the second of some duplicated field on behalf of his
own domain, whilst hoping that some lenient MUA will display only the
first. In others, a genuine signature from the domain under attack is
obtained by legitimate means, but extra header fields are then added,
either by interception or by replay.
As Pete has pointed out -- and has he's adamant about -- the signer
can't attack... that is, DKIM can't do anything about "attacks" by the
signer. And that's as Charles's text itself points out. So I'd be
happy merging just the last sentence with the next paragraph, and
eliminating the rest:
"A genuine signature from the domain under attack can be obtained by
legitimate means, but extra header fields can then be added, either by
interception or by replay. In this scenario DKIM can aid in
detecting such addition of specific fields in transit. This is done
by having the signer list the field name(s) in the "h=" tag an extra
time [...etc...]"
Barry, as participant
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html