At 15.03.2003 21:06 -0600, meor(_at_)mail(_dot_)SoftHome(_dot_)net wrote:
Cool for bad guys who want to do denial of service attacks to
freemailsers like hotmail, gmx, etc. You would just have to get an
account from one freemailer and send hundrets of mails to several
mailboxes at your own pseudo server. Your pseudo server then behaves like
the box at the freemailer is unthrusted and replies with a uncrypted
random message and a different crypted random message. The freemailer's
server will be unable to find the right key. Even if there is a limit,
how long the freemailer's server will try to find the right key, it will
take more (cpu) time than usual.
The situation would be even worse if someone overtakes a normal server
and replaces it with such a pseudo server. All servers sending messages
to this one would be slowed down
In the case of web clients the computer that would have to do the
computation load would be different. Clearly, as you said, a free mail
server should not have to perform the computations because, as you stated,
that would be open to a DoS attack. A simple solution to this would be
possibly giving the web client an applet the performs the computations on
the server's behalf. If the sender is required to perform some
computation work, the work load could be encapsulated by this applet and
given to the computer that is requesting the mail is sent. Once the
solution is found, the result would be sent to the web mail client, which
would in turn be sent to the destination mail server. [...]
First of all the problem is not limited to web clients. It's a problem for
everyone who offers a free email service, regardless what clients their
"customers" use.
Your "simple solution" is bad.
Example:
Dial-In user ---> ISP's/freemailer's relay
relay --> final destination (temporally unreachable)
Dial-In user goes offline
relay (retrying) --> final destination
If the final destination is a malicious pseudo server, the *relay* will
have to handle the requested, impossible authentication task.
Even if you would solve this, so a original sender would not be able to
take down relays by using malicious pseudo servers, there remains a problem.
What if a former normal server would be replaced by a malicious pseudo
server (by virus/worm or hack)? All clients would try to solve impossible
authentication tasks, given from the "new" server, no matter wheter the
were whitelisted at the original server or not.
In short: If the destination requests an impossible problem solution (in
result of error, manipulation or whatever) the sender is the one who
suffers. And the sender will not be able to discover this before it has to
suffer.
You do bring up an a valid point that web clients would be harder to
implement, but I truly believe the benefits of this method far outweigh a
slightly harder web client implementation.
I don't think it's a good idea to "solve" problems of the concept in the
implementations. "Needs workaround by design" stinks.
Erm ... and what about replying to the list next time?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg