] Replay attacks and ISP business models (2024)

Permalink

Douglas Otis

2005-08-05 10:18:15 UTC

On Aug 5, 2005, at 10:23 AM, Michael Thomas wrote:

>
> william(at)elan.net wrote:
>
>
>>
>>
>> On Fri, 5 Aug 2005, Tony Finch wrote:
>>
>>
>> Its more or less up to the message signer if unique id is there
>> what that
>> unique id is common for. BTW - why do you think per-message keys
>> are much worse (assuming that the settings is such that results
>> are not to be cached)? In my view it cant be any worse then using
>> DNSBL and that seems to be working ok with multiple lists tested
>> for every received message.
>>
>
> I'm sorry, but I have a real hard time seeing how one can cry about
> the
> sky falling wrt the prospects of some domains in the future delegating
> large numbers of selectors while on the other hand saying that per-
> message
> lookups to the home domain from every receiver will not. At the very
> least, you can't have it both ways.

This "bad-list" lookup would have a minor impact as a negative
result. This lookup would not need to be made when the HELO is with
the signature's domain. A user-key lookup would likely be just as
frequent due to DNS cache concerns. As least with the revocation-
identifier there could be a method to eliminate the lookup in most
cases. A bad identifier could be safely given a long time to live as
well.

-Doug

Permalink

Permalink

Douglas Otis

2005-08-07 00:56:11 UTC

On Sat, 2005-08-06 at 22:05 +0000, John Levine wrote:
>
> DCC users are all familiar with this problem, since it means that we
> have to manually whitelist all of the mailing lists we subscribe to to
> keep them from being caught by DCC. Having lived with it for a couple
> of years, I strongly think that it's not something that we should try
> to mix into a signature authentication scheme. If it's important for
> DKIM, why wasn't it equally important for S/MIME and PGP?

This concern seems to center on the general goals of DKIM. Rather than
declaring user-keys, as with S/MIME and OpenPGP, DKIM allows the entire
domain to share the same public key. When done in this fashion, the
impact created by per-domain keys, rather per-user keys, would represent
an incremental increase of traffic carried by DNS. Domains also provide
non-uniform distribution of use, which also helps to minimize the
impact. Here DKIM establishes an accountable domain that should respond
to reports of abuse, in order to retain a good reputation and to protect
their recipients.

User-keys in DNS could have a significant impact on DNS traffic. When
compared to the overall traffic carried by the the messages, this would
represent just a percentage of increase. But when considering the
impact on DNS cache, the effects could be far greater. Perhaps one
solution for protecting the DNS cache would be to severely limit any TXT
or KEY record's TTL. However, short TTLs for user-keys AND domain-keys
would impact the overall performance of email, as every operation would
likely suffer a DNS lookup, with perhaps an increase in the already high
DNS response loss rate. With long time-outs and damage to DNS cache,
the affect that user-keys may have on DNS could be damaging other
applications as well.

With per-user keys, such as with S/MIME, key revocation is solution to
address abusive behavior, which includes abusive replay. When not using
IP address based reputation, but instead depending upon a verified
signature, the normal means to protection reputation are lost. These
normal techniques include rate limiting, monitoring log errors, and of
course canceling accounts. None of these normal techniques will be
affective against abusive replay. With a domain-key used across a large
domain, key revocation is not practical, nor perhaps is the use of user-
keys in DNS. This does not mean there is no solution. It is clear the
revocation-identifier mechanism suggested to address this issue, is not
well understood.

Indeed there could be a centralized repository that holds the hash of
all signatures used in messages identified as abusive. The definition
of abusive is always established by this central repository. There is
no need to define abuse, this third-party must establish the criteria
for abuse.

The revocation-identifier offers an alternative. The signing domain
that receives reports of abuse based upon the revocation-identifier,
could create their own revocation-identifier "bad-list" in the same
manner as a black-hole list (which is currently done at every
connection). A negative results is short lived and uses a minimum of
resources. The signing domain would have the ability to defend their
reputation, and act quickly when there are reports of abuse. The
revocation-identifier would not depend upon monitoring DNS logs either,
as some have suggested.

To reduce the burden of doing an A record lookup to check whether a
revocation-identifier is in the bad-list, this step could be skipped
when the HELO is within the signing domain. In this case, even a
reputation check done on the HELO would not need to be repeated for the
signing domain either. By allowing this two step HELO/signing domain
check, there is a means to defend network resources from DoS attacks as
well.

A centralized hash of signatures of known bad messages simply does not
scale as well, can not be as responsive, nor will this centralized
approach provide those directly affected any say. If anything, the
problems this centralized approach could create may lead to abandoning
the use of domain-keys. This may be replaced by user-keys, or the
entire scheme dropped as unworkable.

A user-key is key delegation. It makes no sense to say some delegation
is absolutely required, but then leave those domains that don't give
each and every user their own key, no means to address replay abuse. I
don't agree that the 'g=local-part' is not a user-key. This muddling
with user-key definitions represents a failure to recognize what DKIM is
providing, an accountable domain.

Some company may want to provide an ad agency a delegated key. The ad
agency will likely be well compensated and would hope for a continued
relationship. There are any number of messages this ad agency could
send that would cause them to have their key revoked and their
relationship terminated. Publishing the message with the wrong local-
part would be likely low on the list of potential problems. I would
suggest a flag be added that indicates the key is delegated where the
selector is then treated as the revocation-identifier.

There should also be a provision to indicate that "third-part"
signatures be allowed only when within the signing domain. This would
permit a company to delegate keys to less trust-worthy entities, but
where they clearly indicate these keys represent different accountable
domains. Those with sufficient clue could quickly locate those
accountable for delegating the keys causing a problem. Allowing the
domain themselves an ability to quickly stop a problem would be the best
method to prevent future problems.

Either the domain is accountable and is both careful and responsive with
respect to key delegation, or they are not. Those that are not, deserve
the reputation they obtain. It is unreasonable to expect there can be a
policy that says only this amount of a user-key approach can be used in
DNS. Recognize that DNS can not properly support a user-key approach.
By allowing the sub-domain "third-party" signature restriction actually
better mitigates the risks of delegating keys.

DKIM does not assure the local-part! Ever. Those that wish to make this
assurance must do so independent of DKIM. One method would be provide
authenticated access to their administrated SMTP servers on port 587, or
even port 443 if needed. Otherwise, the sub-domain "third-party"
signature restriction is still much better than nothing. I would even
argue, much better than user-keys in DNS.

-Doug

Permalink

John R Levine

2005-08-07 03:03:19 UTC

> How interesting that you think we cannot describe an attack unless we
> know the mental state of the attacker.

In this case you are correct, because there is no technical difference
between a "replay attack" and a "mailing list". Your bank robbery
example fails because there are plenty of differences other than mental
state between a normal withdrawal and a bank robbery.

> I really don't know the mental state of the spammers who send most of
> the spam I receive, does that mean I cannot begin to describe how they
> sent the spam?

You can do so, but that's not what you're doing. You are making a
prediction about how they might send spam in the future, without anything
other than your hunch to back it up.

> Actually, I was thinking that zombies would be the primary vehicles
> for the replay. This mailing list centric view of the attack would
> lead people to believe that it is the only method. I much prefer the
> current wording.

Oh, my. I would have thought my point would be blindingly obvious, but I
guess I'm still not getting through. First, I am NOT saying that spammers
will spam through mailing lists. Here's what I'm saying:

Every description of a "replay attack" is also a description of a
mailing list. Anything that stops mail delivered by "replay attacks"
will also stop mail delivered by mailing lists. The only difference
between the two is mental state. If we think it's spam, it's
a replay attack, if think it's good mail it's a mailing list.

The point of my reworded section 9.5 was to show that its description of a
replay attack is also a description of a mailing list. If you think
they're different, you need give us a way to tell them apart without
resorting to mental states. Having used bulk counters for a couple of
years, I'm fairly sure it's not possible, since if it were, we'd have come
up with something better than a per-list whitelist to keep list mail from
being tagged by DCC. But please, prove me wrong, show us how to tell list
mail from spam by technical means.

If you're going to say that if it's from a zombie it's a replay attack, I
think you're wrong, but if you're right, that's great, all we have to do
is block mail from zombies, something we all try to do anyway and that has
no relation at all to mail signatures, and the problem is solved.

I see no reason to believe that spammers would send massive numbers of
identical messages through zombies, since they don't now. What I see from
DCC and in catchall accounts that collect multiple spams is spammers who
mutate messages to defeat bulk detectors. Since bulk detectors exist now
and are fairly effective (give or take the arms race to recognize the
mutated messages as similar), the direction I see is for spammers to
increase the diversity of what they send, not decrease it.

R's,
John

PS:

> Technologists have a fairly poor track record with predicting the
> future, especially with regard to how others will use technology.

No disagreement there.

Permalink

wayne

2005-08-08 01:33:15 UTC

In <***@mtcc.com> Michael Thomas <***@mtcc.com> writes:

> wayne wrote:
>> Are you seriously suggesting not worrying about the replay attack
>> until it is widespread?
>
> Widespread is different than seen in the wild. At this point,
> there's no evidence that I'm aware of that it's been seen
> in the wild. I wouldn't expect it for quite some time --
> why would they bother right now?

You snipped the part where I explained that spammers have had a long
history of riding on other people's good reputations. Any system that
can not deal with that is useless. That is why we have to bother
RIGHT NOW.

> A lot can happen between
> then and now, so I'm not sure that proceeding way down _any_
> one line of defense is all that wise.

I strongly disagree. Spammers can adapt very quickly and have done so
in the past.

>>> For one, it's not
>>>clear that if domains -- in an effort to maintain their
>>>reputation -- start spam-filtering their outbound mail,
>>>you'd reduce the effectiveness of the so-called replay
>>>attack by about 2 orders of magnitude. It seems to me that
>>>it's pretty likely that they'll find something else to do
>>>if that scenario plays out.
>> I don't see how filtering their outbound will help much in preventing
>> the reply attack.
>
> It doesn't prevent it, it just makes it less likely to be
> a viable vector: if 99% of your spam campaign is not leaving
> the outbound ISP, my guess is that you're going to look for
> other distribution mechanisms. We're already seeing a shift
> on that anyway, right? With zombies, right?

That is the whole point of the the replay attack, you only need one
email to leave the outbound ISP with the signature, and then you can
send it a million times via other sources.

Or, if you are saying that all spam problems can be solved if all mail
sources do a better job of filtering on the outbound, then sure. But
then, what is the point of DKIM?

> I really like the formulation I heard here: a lot of the
> utility of signing is in just getting spammers and other
> miscreants to attack somebody else instead of me. Eventually
> we may be able to close the noose, but until then I'd just
> assume at least they not sully my name.

But with the replay attack, there isn't any reason for the spammers to
attack anyone else. They want the reputation of others to help them
pass spam filters.

-wayne

Douglas Otis

2005-08-08 01:42:12 UTC

On Sun, 2005-08-07 at 18:02 -0700, Michael Thomas wrote:
> wayne wrote:

> > I don't see how filtering their outbound will help much in preventing
> > the reply attack.
>
> It doesn't prevent it, it just makes it less likely to be
> a viable vector: if 99% of your spam campaign is not leaving
> the outbound ISP, my guess is that you're going to look for
> other distribution mechanisms. We're already seeing a shift
> on that anyway, right? With zombies, right?

The spam campaign may be messages signed by your domain sent from
various places. The spam campaign would most likely avoid repeating any
spam from the signing domain to avoid being detected. The spammer would
just be sending single messages to themselves. They would already have
other distribution methods looking to capitalize on your signature's
reputation.

> I really like the formulation I heard here: a lot of the
> utility of signing is in just getting spammers and other
> miscreants to attack somebody else instead of me. Eventually
> we may be able to close the noose, but until then I'd just
> assume at least they not sully my name.

A replay attack will sully the domain name. This will remain a problem
for large domains. Make a convincing case for the use of DKIM where the
>From or the Sender headers are not bound to the signature. I would
expect the majority of email will be sent in this manner by major
providers. For DKIM to provide a suitable solution for the general
case, it would need to consider dealing with the replay attack, and DoS
defenses based upon domain name acceptance criteria.

-Doug

Permalink

Douglas Otis

2005-08-08 06:26:09 UTC

On Sun, 2005-08-07 at 21:53 -0400, John R Levine wrote:

> > The damage done to mailing lists reputation may also be the effect of
> > collateral damage caused by other servers sharing the same IP address
> > space.
>
> No, that's not what I said. Please go back and re-read my previous
> messages, paying particular attention to the fact that what mailing lists
> normally do, with no abuse at all, no spammers involved, nothing other
> than what they do every day in correct operation, is identical to a
> "replay attack",

I agree mere existence of replicate signed messages would not be a
positive indication of spam. Schemes that attempt to filter messages
based upon replicate message rates are error prone, and this would
include those messages seen from a mailing list. This would be true
regardless as to whether the mailing list re-signed messages or not.

You make a good point such methods used to detect abuse would require
extensive white-listing to avoid errors. While mailing lists re-signing
messages may allow the white-list to be based upon names, it would be
more likely that the white-list would be IP address based anyway.
Reputation would then still include the IP address, which would not
provide protection from collateral damage when using the IP address for
white-listing.

> The damage to mailing lists has nothing to do with "other servers sharing
> the same IP address". The damage to mailing lists is that any scheme that
> prevents spammers from delivering 100 copies of a message to spam
> recipients will also prevent mailing lists from delivering 100 copies of a
> message to the recipients who asked for it.
>
> Any so-called replay prevention scheme is a direct attack on the normal
> operation of mailing lists. Can I make that any clearer?

I agree with you about not being able to depend upon a key or
revocation-identifier lookup rate compared to the signing rate as a
means to know whether there is a replay attack. An abnormal change in
the account as determined by the revocation-identifier, when seen in
conjunction with abuse reports, would be strong evidence there may be a
problem. Prior to signatures, the administrator may have depended upon
error logs, or abnormally high sending rates as confirmation of abusive
behaviors when investigating abuse reports. Signatures unfortunately
blind the administrator to possible replay abuse. The revocation-
identifier would provide some oversight that would be otherwise lost.

The only point I ever attempted to make along these lines would be that
a revocation-identifier once again provides a general indication of
_possibly_ abusive behavior. The administrator would need to confirm
their suspicions using other techniques. Abuse reports that highlight
the revocation-identifier could be helpful in this process of course.

-Doug

Amir Herzberg

2005-08-08 13:07:58 UTC

John R Levine wrote:
>>>indistinguishable from a "replay attack." I'm still waiting for someone
>>>to explain how you stop replay without also wrecking mailing lists, other
>>>that by implausibly labor intensive approaches like manually whitelisting
>>>every legitimate remailer in the world.
>... what mailing lists
> normally do, with no abuse at all, no spammers involved, nothing other
> than what they do every day in correct operation, is identical to a
> "replay attack",
...
> Any so-called replay prevention scheme is a direct attack on the normal
> operation of mailing lists. Can I make that any clearer?

Good point: automatically rejecting forwarded DKIM mail may interfer
with current mailing lists. However, I think John is too quick in
concluding that this prevents any `so-called replay prevention scheme`.
Or in other words, maybe we can control replay, rather than flatly
reject (prevent) any replay.

Controlling replays implies that when we receive e-mail, we identify
three DKIM classes:

Class 1 (non-DKIM) - Unsigned mail (i.e., no DKIM services).

Class 2 (no-replay-protection DKIM) - Signed (DKIM) mail w/o
replay/destination protection. Here, the current destination is not
covered by the signature (typcially, the original destination was
mailing list, which just forwarded this message).

Class 3 (`full` DKIM) - Signed (DKIM) mail with replay/destination
protection. Here, the destination is signed (or just a hash of the
destination, possibly using hash tree, for privacy and efficiency).
Mailing lists and other forwarding services will need special
DKIM-enhancements to provide this DKIM service. This will not work of
course for current forwarding and mailing list systems (but will work
for enhanced, DKIM-supporting systems)

Recipients do not have to discard e-mail from classes 1 or 2. Indeed,
they are not likely to do so, at least in the near to medium term.
However, this does give DKIM the ability to protect against replay.
Namely, blacklist servers will be aware that class 2 DKIM does not
protect against replay - and will not be hasty to conclude that the
responsibility for the spam is on the original sender. It may be on the
forwarding agent - a mailing list or a Zombie.

p.s. this message is cross posted to MASS WG since John sent there his
post (and also I sent my orignal note there), but please respond to
IETF-DKIM since discussion moved there.
--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame

Amir Herzberg

2005-08-08 14:18:55 UTC

John R Levine wrote:
>>>indistinguishable from a "replay attack." I'm still waiting for someone
>>>to explain how you stop replay without also wrecking mailing lists, other
>>>that by implausibly labor intensive approaches like manually whitelisting
>>>every legitimate remailer in the world.
>... what mailing lists
> normally do, with no abuse at all, no spammers involved, nothing other
> than what they do every day in correct operation, is identical to a
> "replay attack",
...
> Any so-called replay prevention scheme is a direct attack on the normal
> operation of mailing lists. Can I make that any clearer?

Good point: automatically rejecting forwarded DKIM mail may interfer
with current mailing lists. However, I think John is too quick in
concluding that this prevents any `so-called replay prevention scheme`.
Or in other words, maybe we can control replay, rather than flatly
reject (prevent) any replay.

Controlling replays implies that when we receive e-mail, we identify
three DKIM classes:

Class 1 (non-DKIM) - Unsigned mail (i.e., no DKIM services).

Class 2 (no-replay-protection DKIM) - Signed (DKIM) mail w/o
replay/destination protection. Here, the current destination is not
covered by the signature (typcially, the original destination was
mailing list, which just forwarded this message).

Class 3 (`full` DKIM) - Signed (DKIM) mail with replay/destination
protection. Here, the destination is signed (or just a hash of the
destination, possibly using hash tree, for privacy and efficiency).
Mailing lists and other forwarding services will need special
DKIM-enhancements to provide this DKIM service. This will not work of
course for current forwarding and mailing list systems (but will work
for enhanced, DKIM-supporting systems)

Recipients do not have to discard e-mail from classes 1 or 2. Indeed,
they are not likely to do so, at least in the near to medium term.
However, this does give DKIM the ability to protect against replay.
Namely, blacklist servers will be aware that class 2 DKIM does not
protect against replay - and will not be hasty to conclude that the
responsibility for the spam is on the original sender. It may be on the
forwarding agent - a mailing list or a Zombie.

p.s. this message is cross posted to MASS WG since John sent there his
post (and also I sent my orignal note there), but please respond to
IETF-DKIM since discussion moved there.
--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame

wayne

2005-08-09 04:01:13 UTC

In <***@tom.iecc.com> "John R Levine" <***@iecc.com> writes:

> You're also making the assumption that spammers will blast out many
> identical messages with the same signature. They stopped doing that in
> about 1999,

That's interesting. I took a quick look at my spam folder and quickly
found identical copies of spams delivered to just me. I didn't bother
to look to see at any of the spam sightings collections to see how
many individual spams delivered to me were also delivered to others.

> and nobody's suggested what would make them resume doing so.

That is also interesting. I recall several people saying that riding
on other people's reputations would be a good reason why spammers
might want to do so.

> It's far more likely that they'll keep doing what they're doing now,
> sending out messages that are all different, or at most sending to a
> handful of recipients before changing the message. Replay protection,
> even if it's possible, is of no help.

Well, I guess it all depends on what you define as "a handful".
Nothing is stopping a spammer from replaying just one email. They
could probably generate hundreds or thousands of variations before
they start their spam run.

Well, you may be right that replay protection may not be possible, or
that it may be of little help.

That kind of raises the question though: What good does having a DKIM
signed email give us? Why, as a domain owner, would I want to sign
email? Why, as a email receiver, would I want to check the signature?

I thought I knew what people would give as the answers to those
questions, but it is clear that others have different ideas of the
goals and benefits of signing email.

-wayne