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 <c...@clerew.man.ac.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