Hector Santos wrote: > ----- Original Message ----- > From: "Jim Fenton" <[EMAIL PROTECTED]> > To: "Hector Santos" <[EMAIL PROTECTED]> > Cc: <[email protected]> > 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
