ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-06 15:55:01
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

<Prev in Thread] Current Thread [Next in Thread>