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