On Sun, 2005-02-13 at 17:30, Jim Fenton wrote:
Douglas Otis wrote:
On Fri, 2005-02-11 at 15:54 -0800, Jim Fenton wrote:
The reputation might also depend on the responsiveness of the domain
when a problem is discovered. Or perhaps this is an argument for some
combination of reputation and accreditation.
This would be assuming reputation is based upon the remote IP address.
In such a case, server reputations can be retained by canceling abusive
accounts and monitoring logs. A signature however can be
"authenticated" regardless of the remote IP address, and hence canceling
accounts and monitoring logs alone would be ineffectual reputation
protection as abuse could continue unabated as "replays".
I don't see any relationship to the use of IP address as an identifier
in the above discussion. I was talking about signatures, and I think
Sam was too.
Without a revocation mechanism, it remains _impossible_ to be responsive
to spam already signed and being sent in bulk. While reputation based
upon the sending MTA's IP address affords an ability to respond, a
reputation based upon the signature without a revocation mechanism does
not!
Not if they read section section 9.1.4, "Message Replay Attack", of the
IIM draft. We have tried to be as upfront as possible about the
limitations of message signing.
Rather than taking a finger-print of the message as described in 9.4.1,
establishing persistent revocation identifiers would offer opportunities
to prevent this threat.
The countermeasures described there aren't intended to be used; they're
illustrations of the problems associated with trying to "fix" the
message replay problem.
A case can be made that a revocation mechanism would be easier to deploy
and less burdensome, than using a key-per-user for large domains. A
persistent "revocation identifier" would also assist in locating
compromised systems, and with the correlation of abuse by various
parties. The persistence could be based upon the authentication process
that initially grants access to the signing SMTP server.
Reputation must be based only upon authenticated identifiers, which
underscores limitations establishing assurances for specific
mailbox-domain.
Even the revocation identifiers you're advocating might have a problem
with mailing list replays. If a message gets signed by a mailing list
and then replayed, do you revoke the mailing list's authorization?
Hopefully not; this might interfere with other messages in transit. Do
you then put a unique revocation ID on each message? That adds a whole
new dimension to the scaling problem.
As most mailing lists authenticate recipients on some basis, this too
could allow a persistent identifier. If abuse is determined to be from
jon(_dot_)doe(_at_)example(_dot_)com (assigned a persistent identifier
ML03-02345) signed
by the mailing list mailing-lists.com, then bulk spam bearing their
signature with this identifier can be squelched by a simple
blackhole-listing of:
ML03-02345._rl.mailing-lists.com
This should not interfere with other messages in transit. Jon Doe too
could sign his messages as condition of acceptance to ensure no future
problems. Once Jon signs his messages, the mailing list could opt to
not alter the content of these messages and leave his signature intact.
If there is a problem discovered, then example.com would then need to
protect their signature instead.
Replay must be allowed until abuse has been reported or detected. An
optional revocation identifier would allow both protection of the
signature reputation, and provide a means to detect when abuse may be
occurring.
But once the replay has been detected, the damage (dissemination of the
spam) has basically been done.
Damage can be mitigated when there is a revocation mechanism. This can
take place within the same time-frame as canceling their account now
takes. In fact, the same scripts that cancels the account should
publish the revocation.
Once beyond the TTL from the removal of the signature, the revocation
record can then be deleted. This could be implemented where the removal
of a signature also removes the prior signature's revocations.
I'm concerned about the time urgency of the revocation: how quickly
must the domain publish a revocation of a particular identifier in
order to prevent damage to its reputation?
While rate limiting is not an available tool for signatures, the
revocation mechanism (as described) could provide a warning there may be
a rate problem when an unusually high query rate occurs for a record at:
ML03-02345._rl.mailing-lists.com
This revocation mechanism provides more equal footing with respect to
defending the reputation of a signature, compared to that of defending
the IP address of a server. The speed of the response would need to be
comparable. There is an advantage using signatures, in that there would
be little doubt about the authenticity of an abuse report. The
revocation identifier could also facilitate automated cancellation and
revocation scripts. Life should actually be easier by using signatures
with a revocation mechanism.
The revocation ID can be used to prevent a particular user from
sending more than one message for replay, but why wouldn't they just
get a new account for each message they want to replay?
Spam is a game of numbers. Much like responding to the broken window in
the warehouse, staying on top of an abuse problem makes abusing these
accounts less profitable (no glory) and therefore less likely. A
signature with a revocation identifier enables the automation of this
process. By keeping a spam problem in better check, signatures would
provide a solid basis for trust. A signature's ability to localize
control of problem accounts would also represent a substantial reduction
in abuse related expenditures. This reduction in cost should easily
justify implementation of the signing SMTP servers.
-Doug