ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-10 17:27:37

On Thu, 2005-02-10 at 16:53 -0500, Sam Hartman wrote:
"John" == John R Levine <johnl(_at_)iecc(_dot_)com> writes:

John> This is the Project Lumos fallacy.  I have no interest whatsoever in
John> distinguishing between a domain's nice users and its nasty users.  I
John> believe that each domain is responsible for keeping its users in line, 
and
John> the reason that signatures are useful is to help me alert domains about
John> undesirable mail they've sent.  If they send a lot of undesirable mail,
John> I'm going to reject the whole domain, not do their filtering for them.

As discussed in section 4.1 of Russ's draft, a domain cannot know how
widely a message will be distributed.  Once I have a signed copy of
that message I can choose to distribute it much more widely than the
sending domain might like me to do.

Agreed.

Fundamentally what you are asking for is incompatible with ISPs that
will provide service to users until those users violate the terms of
service.  The user can take one action--signing one message and widely
distribute that signed message.  

For a large ISP this will happen enough that your strategy will end up
deciding all the large isps have unacceptable reputations.

Agreed, but there could be a solution.  Per-user keys, as suggested,
would result in deployment issues where, for a large domain with 20
million users, 14 GB of data would be required, and, to quickly revoke
authorization, be published with short cache TTLs.

Optional opaque identifiers combined with the signature could be an
alternative.  The domain could revoke authorization by publishing an
identifier-labeled A record with a 127.0.0.0/8 address.  While many
smaller domains may not require or use this mechanism, larger domains
could use this blackhole-listing approach to effectively squelch
"replay" abuse.

A domain using signatures would retain their reputation by responding to
abuse reports, where the signed opaque identifier would assure the
correct accounts are terminated.  These identifiers could serve to
address two issues.  Identify users with compromised systems by
correlating abuse, in addition to stopping "relay" attacks.

The revocation mechanism would be fairly simple to implement.  If done
rapidly and consistently, the number of such events should remain
infrequent, as there would be little profit abusing in this manner.
Once an abusing account is discovered, both blackhole-listing and
refusing SMTP access would be effective measures protecting reputations
and abating abuse.

Most of the abuse today comes from a high percentage of compromised
systems.  Spending $40 does not prevent this problem:
http://www.zdnet.com.au/news/security/0,2000061744,39180674,00.htm

The signature, without an additional identifier, does little to address
the problem of abuse.  Without curtailing a "replay" attack and
identifying compromised systems, the value of a signature is greatly
depreciated as an abatement tool.  The "replay" risk is present for
web-based mail providers as well as access providers.  Signatures, with
an ability to rapidly respond, will change the incentives.

There should not be an expectation abusers will employ technology
effectively at blocking.  With millions of compromised systems however,
it is likely abuse will mix with legitimate messages. Should there come
a time where the signature's reputation becomes a factor for acceptance,
this serves as a "replay" incentive.  Without a signature's reputation
being a factor for acceptance, what is the value in domain signed
messages?

-Doug
  





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