Amir Herzberg wrote:
Hallam-Baker, Phillip wrote:
Surely what an optimized implementation would do is look to see if the
reputation is in the cache, if so and the reputation is bad then throw
out the message and stop processing.
Otherwise verify the signature and only look up the reputation if it
verifies.
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).
If not... then the DoS attack of sending mal-signatures remains.
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.
-Jim