Hallam-Baker, Phillip 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.
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
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)?
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. Some proposed options:
-- No DoS protection required (current DMIK)
-- `Anti-DoS computation cookie`: specifies a hash-cash like challenge
<x,k> s.t. the sender must find string y s.t. h(m, x, y)=z||0^k, where m
is the (digest of?) message and h is a hash function e.g. SHA1.
-- `Anti-DoS IP-based cookie`: specifies an IP address of a `cookie
server`, to which the sending MTA should send a request, and get back a
cookie to be added to the message (like in IKE).
-- `Anti-DoS 3rd-party cookie`: specifies one or more third party
DoS-prevention servers, which share a key with the recipient. Sender can
contact any of them, send the the signature, and get back a cookie
(which is a MAC over the signature and/or original message, and the
identity of recipient). This may require some long term relationship
with 3rd party and/or payment to 3rd party. Notice that with this
option, it may sometimes be possible to avoid validating the signature
at all in the recipient.
Department of Computer Science
Bar Ilan University
Try TrustBar - improved browser security UI:
Visit my Hall Of Shame of Unprotected Login pages: