[ietf-clear] callbacks are groovy

On Tue, 5 Oct 2004, Douglas Otis wrote:
> Would there be an advantage having a scheme that offered some level of
> replay protection when a bounce is detected by way of the signature?
I'm not sure exactly what you're getting at, so I'll wibble for a bit.

Currently SES uses relies on recipients to help with foiling replay
attacks, by tying the bounce address to the message data by including
a message data hash in the bounce address.

Before that became the consensus mechanism, the SES group discussed other
possible ways mostly based on detecting how bounce addresses are being
used. You can do this by keeping track of bounce messages, SMTP callbacks,
SPF exists: DNS callbacks, or whatever other callback mechanisms you
create. This has two disadvantages: maintaining a database (which we
would like to avoid for the reasons that John described); and the feedback
isn't that good anyway (because most messages don't bounce and callback
mechanisms aren't widely deployed).

The second problem can be almost completely fixed by putting the tag in
the domain part of the bounce address. (This is the approach I am working
on.) A large proportion of MTAs verify remote email domains by checking
that they have a plausible DNS setup, so we'll receive DNS lookups for the
tagged domain from message recipients. We can prevent recipients (who are
running existing unmodified code with standard configurations) from
receiving messages with excessively old bounce addresses, or messages with
attacked bounce addresses, by giving them an NXDOMAIN answer instead of an
MX record.

This still leaves the problem of maintaining a database. Actually, there's
a more fundamental problem: I don't know if it'll be possible to use MX
lookup behaviour to track abuse. So my project is rather speculative :-)
but I'll assume for the time being that it isn't a wild goose chase, in
which case I have to address the database problem. There are some features
of this system which make it much simpler than the word "database"
suggests. In particular you don't have to maintain records for every
message you've sent for the whole of their lifetime across all of the
verification servers with consistent data, because the records are being
used as input to a heuristic process (abuse detection) which doesn't need
perfect accuracy.

It's worth noting that although the lifetime of a bounce address has to be
quite long (weeks), in the usual case it has finished being used within a
few seconds. You probably don't need to keep live information about an
address longer than that (whether the address is new or old). This guess
is also based on observing the bursty nature of message transport.

Also, the older an address is (which you know because the tag includes a
timestamp) the less likely you are to get lots of MX lookups for it, even
if it started off with lots of recipients. Therefore you can use
rate-limiting to restrict borderline-plausible use of an address, by using
SERVFAIL DNS responses or even no response at all.

So far we have not introduced any persistent state into the system, or any
state that has to be shared between multiple systems. This is required if
you are going to disable an address before the end of its normal lifetime.
However it doesn't have to be prompt or synchronized across a cluster
(remember this is the result of a heuristic; we're mitigating rather than
preventing). So you can have the public-facing DNS servers logging at a
low rate to a back-end server which decides when to disable an address and
tells the public servers accordingly.

-----

The above is all about attacks using tagged addresses. We expect them to
be rare, especially at first. In the mean time attacks will mostly use
untagged addresses in the return path, and the above does nothing to
help recipients deal with them. There are a few possible approaches:

SMTP or UDP callbacks scale according to the volume of attack traffic, so
are not desirable.

SPF exists: callbacks scale per user. (Actually they aren't really
callbacks; in this scenario they're being used to discover whether or
not the user tags their bounce addresses.) You can be careful with DNS
TTLs and the siting of your DNS servers to minimize the cost (e.g. use
off-site DNS caches to take the lookup load off your T1).

MPR scales per domain. However my deployment requires bounce address
tagging to be a per-user option, so MPR isn't usable.

I'm therefore going to specify a per-user DNS lookup mechanism which
allows a recipient to find out if a given bounce address should or should
not be tagged. It doesn't have to be specific to my domain-tagging scheme;
it can work with BATV or SES or whatever.

Tony.
-- 
f.a.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
BISCAY: WESTERLY 5, OCCASIONALLY 6 AT FIRST IN NORTH, BECOMING VARIABLE 4 IN
SOUTH. RAIN OR SHOWERS. MODERATE OR GOOD.