ietf-mailsig
[Top] [All Lists]

Re: epostage, hashcash, callbacks, was MASS Security Review document

2005-02-15 13:23:20

On Tue, 2005-02-15 at 13:58 -0500, John R Levine wrote:
 Indeed, any scheme that requires a callback per message has severe 
scaling
 problems.  

Let's make sure there is a clear distinction between what is being
labeled "callback", versus the DNS query needed for some of the proposed
authentication schemes:

If it wasn't clear, what I am concerned about are the per-message ticket
schemes that Doug mentioned, and signature or revocation schemes that have
a per message granularity so that the recipient makes a different DNS
query for each message.

Consider RBL and DUL lists are based upon negative caching.  While this
traffic is not minor, it is something handled for all domains using
billions of identifiers (IP addresses) which approach per-message rates
for normal mail.

For the receiver, a query for a revocation-identifier would be limited
to the portion of domains that employ this option.  For the sender,
unlike RBL and DUL services, only messages from their domain would be
queried against their server.  A large domain should have little trouble
scaling their network to support this traffic.  In most cases, it would
be an exchange of a single, small UDP packet.

Those messages causing the greatest traffic would also likely return a
long lived record that marks the messages as spam, and save both the
sender and receiver from experiencing excess traffic as a result.
Should the mechanism prove to be of little benefit (once everyone is
inoculated), the recipient could easily neglect these check.  That will
be the day. 

Whereas the auth schemes are not per-message and don't even have to be
per-user, so the data being queried are relatively stable. Updates do
not have to be all that frequent.

Systems like Domain Keys can have any granularity from one key that lasts
forever to a new key for each message.  The farther you move toward the
latter point, the worse the scaling problems become.  I am concerned that
people who are suggesting finer granularity don't appreciate the
performance problems that can cause.

I agree keys are problematic when considering how an account could be
revoked.  Either these keys are published with short TTL values and
require frequent updates of large UDP packets transferring gigabytes of
data, or revocation become impractical.

I also agree epostage is a difficult problem and would invite  exploits.
With epostage being a stateful process running HTTP, the ability to
scale would also likely depend upon persistent connections, where stack
limitations would require a large number of dedicated servers.  This is
not impossible, just expensive.  Should each thread in the mail stack
attempt to establish connections, the cost becomes significant.

When most spam is already coming from compromised systems, epostage or a
single domain key without a revocation-identifier appears extremely
flawed.  It just means there is yet another reason someone's computer is
running slower than normal. : (

-Doug



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