Re: [Asrg] request for review for a non FUSSP proposal

[Claudio Telmon <[e-mail]>]

Rich Kulawiec wrote:

> This is unworkable for multiple reasons, not the least of which of scale:
> as of a few years ago, there were at least a hundred million compromised
> systems, and the number today is certainly much higher.  There's no
> good way to inform the former owners of those systems, there's no reason
> to believe that they'll see the notification (especially if automated,
> since the new owners of those systems can prevent them from seeing it),
> there's no way to stop those systems from emitting bogus notifications,
> the recipients' systems may themselves be compromised, etc.  Not to
> mention it's a LOT of work for everyone to keep track of all these tokens.

While what you say is true in general, I think you missed a critical
part of the consent framework I'm proposing. A consent-enabled address
will only accept messages from senders that received a valid token for
that address though some channel (usually, not email). That is, each
sender will only have tokens for consent-enabled addresses he received a
token for, which is comparable to the number of addresses he has in his
address book. If the sender's system is compromised, the
attacker/spammer will only collect tokens for these addresses. The
spammer can send spam to any non-consent-enabled address, but this is
outside the scope of the framework. The spammer can however send
messages only to the consent-enabled addresses he has tokens for, which
are the people in the address book of the compromised system. These are
the (few) people the system owner is in direct contact with, which will
detect which token is used in the spam they receive and therefore whose
system was compromised. The owner of this system will be informed,
possibly not via email, and the tokens will be invalidated anyway. The
other millions of compromised hosts are not relevant in this scenario:
even if the spammer distributes the tokens to these hosts, or sells the
address and the token in a list, all this becomes useless once the token
is invalidated, which should happen almost immediately after a couple of
spam messages.
At this point, those receiving the spam can decide if they want to issue
a new token for the (once) compromised sender, provided that its host
has been cleaned. If they keep receiving spam with the new token, they
surely will revoke this token too, and will be put in front of the
problem of their relationship with somebody that is not able to keep its
system clean. With respect to consent-enabled addresses, it would turn
the problem of informing the owners of millions of compromised systems,
into a "local" problem of relationships inside small groups of people.


-- 

Claudio Telmon
[e-mail]
http://www.telmon.org