Hector Santos wrote:
----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, April 21, 2006 8:56 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
This points out another problem: if a verifier defers verification or
acceptance of a given message, it SHOULD maintain enough state so that
the message may be accepted after some number of retries, so that
messages with key retrieval problems are not rejected entirely.
Jim,
Wouldn't that create a loophole?
If you mean, how would the verifier know how many deferrals are
acceptable, you're right that's a problem. If the key can't
(permanently) be retrieved, it's a signature verification failure, and
not in general a reason to reject the message outright, so I don't
consider it to be a loophole in that sense.
I was referring to the bad guy finding out:
'Hey Fellas! All we need to is create error conditions,
beat down the verifier enough so that eventually it
give up and accept our payload. The beauty? No
need to have a correct DKIM signature! Just fake it."
A DKIM Greylisting-like concept is a terrible idea Jim. :-)
I agree with you, and that isn't what I was proposing.
Signatures that can't be verified should be treated the same as invalid
signatures, which in turn should be treated the same, no better or
worse, than signatures that aren't there. Otherwise an attacker will
just create a signature that references a name server that just doesn't
seem to be online, and if that causes the message to be treated better,
they'll take advantage of it.
I'm also concerned about the burden of maintaining state, possibly even
in the form of queued messages, when the public key is "temporarily
unavailable". There is the potential to create a DoS attack by making
the verifier queue too much. The verifier needs to be aware of this and
just give up on verification when things get too busy.
IMV, DKIM is a new era of expectations. A domain with a DKIM signature not
only is claiming responsibility for the message, it is also claiming it is
compliant with DKIM.
PS: It is a reason to reject the "transaction."
One problem is that the verifier need not be the edge MTA (MX host), so
the recipient AU may have already accepted the message. Another is that
rejecting a message outright based on the lack of a signature isn't
going to be practical in most cases for quite some time to come.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html