ietf-mailsig
[Top] [All Lists]

Re: Proposals Re: DoS and Replay protection for message signatures

2005-08-03 07:24:52

Jim Fenton wrote:
Amir Herzberg wrote:
...
Would you reduce reputation if you get multiple signature verification failures? Up to throwing messages without validating signatures? I think that's what you (and Tony) suggest.

If so... can't an attacker abuse this to perform DoS on _senders_, by thrashing their reputation by sending malsigned messages (also hitting some recipients at the same time)?

I'm convinced that one can't draw any conclusions at all on an invalid signature. It might as well not be there, except if some other valid signature has signed it (in which case you need it to verify the valid signature, nothing else).
I agree. So...

If not... then the DoS attack of sending mal-signatures remains.
Do you agree? Should we care? If not, we should at least document in Security Considerations. If we do, we need to think of solutions. I proposed some in my note...

We can solve this by placing the burden on the senders. Add a `recipient policy` record for the _recipient_ (in a DNS record). This record identifies what the recipient requires from incoming messages, to prevent them being thrashed as DoS.

How can a sender/signer know what the recipient is? Transparent forwarding has important privacy properties; the sender must not (in general) know where the message was eventually delivered.
Sorry; my solution really focused on a known DKIM receipient (border) MTA, and I implicitly assumed that if DKIM is used, it is by the sending (border) MTA; in this case, of course, there is not privacy issue. You are right, this may be an imporant scenario but we also want to allow intermediate non-DKIM MTAs, including of forwarding domains.

One solution is as follows. As long as a receiving MTA is _not_ under DoS attack, it works as in current spec. But if it is under DoS attack, and cannot spend resources to try to validate yet another signature, both for computational and other resources (e.g. required to accept the DATA part), then it MAY reject the connection (with 550?), indicating `DoS-prevention mode, resend with cookie`. Here, cookie can be: -- simply an opaque byte stream quickly verifiable by sender (IKE-like :-), or
-- A `hashcash-like` challenge (as I described earlier)

If the sending MTA is DKIM-aware, it'll simply resend with the required cookie. Otherwise, it will follow SMTP `bounce` processing, and the bounce will be captured by DKIM-aware bounce processor which will perform the resend. The bounce processor may become aware of the mail route but this could happen anyway.

Would it work? Are we better off with the original problem?

--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame

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