From: Scott Kitterman
Sent: Wednesday, September 29, 2004 8:13 AM
<...>
I thought the major point of SUBMITTER was to allow forwarders to
use it and avoid having to rewrite MAIL FROM? In your approach
wouldn't they still have to change MAIL FROM to get the message
accepted?
That's the function of SES. It allows you to verify a MAIL FROM: after a
forward and there is no need for SUBMITTER. It doesn't deal with 2822
headers, but one step at a time.
Recently, Stuart has suggested that the SPF record is a great place to
publish sender policy, but that the idea of publishing designated senders by
IP may be questionable. I congratulate Stuart for having the courage to
voice that observation and I think it's time that we stare that possibility
in the face. There are real problems with listing the IP's of all your
mailers and keeping that up to date. The elegant language that we have
developed allows significant DNS recursion which creates real system loads.
Another obvious problem that more and more people are realizing is that the
validation is only good for the first hop. Validating a forwarder with the
SUBMITTER parameter tells you next to nothing about the validity of the
originating identity in the return-path.
Take a step back and a deep breath and consider where we're at from a
technical standpoint. Designated sending IP's was a great idea, but it only
validates the first hop and it breaks forwarding. The solutions to fix
forwarding cost you the validation of the originating identity, plus you
have to get most of the forwarders to go along with it. That part of the
effort understandably met with serious resistance, which is why Meng
proposed SUBMITTER. That is simpler than SRS, but it still does provide
authentication of the originating site. Since PRA is now completely out of
the question, that leaves us at a dead end for 2821 authentication. Really,
PRA is absolutely not an option anymore, unless you happen to work for
Microsoft. But there's no need to throw in the towel.
Consider that the original goals of SPF were:
1) Validate the MAIL FROM: identity of an incoming message.
2) Provide immunity to joe-jobs.
3) Allow for rejection before data as often as possible.
4) The protocol must be lightweight.
It appears that end-to-end authentication does a better job on these goals
better than designated sending IP's. That's a hard realization to swallow,
but I believe that's the correct technical analysis. It doesn't mean that
we've wasted our time, but some re-evaluation is in order. If we consider
end-to-end validation, there are two general approaches for doing that
today: PK crypto (for example, DK) and SES. Let's take a first pass at
contrasting these two general approaches. There are more similarities that
one might first expect and some important differences.
DK takes a digest of selected parts of a canonicalized message, creates an
RSA signature of the digest with a private key and puts the signature and
digest in a header. The recipient fetches the public key from the domain
DNS and validates the RSA signature. If the signature validates, the
recipient computes the message digest and compares it to the one in the
validated signature header.
SES takes a digest of selected parts of a canonicalized message, signs the
digest using an HMAC with a private key and puts the signature and digest in
the return-path. The recipient looks up the return-path domain MX, if it
hasn't already done so, and sends the return-path in a single UDP packet to
a special port at the MX. The MX then validates or invalidates the
signature and returns the result in a single UDP packet. If the signature
validates, the recipient computes the message digest and compares it to the
one in the validated return-path.
As you can see both systems produce a message digest, sign it, validate the
signatures and then compare the actual message digest to the one in the
signature. The differences are only in the methods of signature and
signature validation. Both schemes give equivalent authentication. Even
though many people mistakenly believe that only PK crypto can give solid
authentication, that is simply not true. An HMAC of sufficient length is
cryptographically secure for the lifetime of the signature. The obvious
question is, why consider SES when we can have real PK crypto
authentication? The answer has to do with the total cost of the message
transaction and how the load is distributed.
With DK, the sender first computes a message digest, which is low-cost. The
sender then creates an RSA signature, which is extremely expensive. The
recipient gets a public key from the DNS, which is inexpensive and can be
cached locally. The recipient then validates the RSA signature, which is
very costly. Once the signature is validated, the recipient computes and
compares a message digest, which is low-cost.
SES starts with the same low-cost message digest as DK. The next step is
computing an HMAC signature, which is only slightly higher cost than the
message digest. The recipient does an MX lookup and sends the return-path
to the MX in a single UDP packet. The sender then validates the signature,
which consists of a lightweight HMAC, and then responds with a single UDP
packet. Once the signature is validated, the recipient computes and
compares the same message digest as in DK.
On balance, DK has two very expensive operations: creating the RSA signature
and validating it. The sender does one and the recipient does the other.
This seems fair, until one realizes that recipients have a large amount of
incoming spam compared to legitimate mail, and now each message will require
an expensive RSA signature validation. With SES, the total load is far
lower and what load there is belongs more to the sender than the recipient.
Many people have argued for many years that the sender should bear more of
the load than the recipient. This is especially true when the sender is
stealing the resources of others to disseminate their payload. Recipients
that get a large amount of spam need a lightweight method of forgery
detection, and the possibility of doing this before data is important to
preserve bandwidth and throughput.
In summary, SES has far lower total message transaction cost than DK and
that cost is particularly lower for the recipient. The authentication is of
equivalent quality. There are several ancillary advantages of SES.
1) It allows recipients to reject messages with forged return-paths before
data.
2) It gives the sender immediate forged null-sender protection.
3) It does not require the sender to publish anything in their DNS for
default operation. An ideal use for the SPF record in this case is to state
what the sender policy is. That is, what protocols does that domain employ
for sending mail and which are required for validation.
4) SES supports per-user and per-site keys in addition to per-domain keys.
The type of authentication is returned with the validation response packet.
For sending sites that sign with per-user keys, the authentication is better
than DK.
5) SES validation responses are returned with a TTL so the recipient can
cache them. This assists in the case of a spam run using the same forged
originating signature. Sender validation servers can also cache both
negative and positive validation results.
A previous objection to SES was the possibility of replay attack with a
harvested signed return-path. Since the SES signature now contains a signed
message digest, the only replay possible would be to send the unmodified
original message along with the harvested return-path. No other message
will validate. Therefore, harvesting return-paths and attaching new message
bodies will not result in a single additional delivery for a spammer. Any
site that would accept the forgery would accept it without the harvested
return-path signature, so there is no benefit to spammers to harvest and
replay signed return-paths.
On the negative side, SES does not support encryption. This is not a
feature required for typical email traffic and the decryption at the
recipient is an additional unwanted load. A second potential objection is
that for a large spam run, there will be a lot of UDP validation requests
directed at the domain MX. Several factors will mitigate this. Recipients
can cache validation results, so that multiple pieces of spam sent to the
same site will only result in a single validation request. The validation
server also limits negative responses to ten per second per IP, and
additional requests are ignored. The messages for which the validation
packets are dropped will receive 4xx temporary failures and are queued at
the sender. Meanwhile, numerous sites will automatically report IP's
sending them forged messages and those sites will appear on black lists or
real-time reputation systems. On subsequent retries of the deferred
messages, many of the connections will be refused without requiring a
validation request.
Finally, IP's that generate 100 or more negative validations in a ten second
period will be banned for a fixed timeout. After the timeout, if they
exceed the limit again, they are banned for a longer period. This is a
common tactic for repelling dictionary attacks and it is fairly effective.
It is still possible that a site with very low bandwidth can have their
network connection saturated with validation requests. Even though this is
theoretically possible, since replays will not result in a single additional
message delivery, it is unlikely that spammers will do that. If their goal
is to DoS a site, this is a fairly weak mechanism due to the lack of
amplification. There are far more effective and simple DoS attacks that no
one can stop. This is a fact of life on the Internet. Your network
connection and your nameservers are generally vulnerable and very little, if
anything, can be done if someone targets you for a large-scale attack.
Sending invalid SES signatures in spam is far less of a DoS than sending
invalid DK signatures, which are orders of magnitude more expensive to
validate. The difference is only the target, and DK (or any other PK crypto
scheme) is a far more potent DoS vector.
There is one more feature of an SES end-to-end system worth considering.
Unlike SPF, an SES failure is definitive. The message is known to be a
forgery. This lends itself to automated reporting to reputation systems,
such as Gossip and blacklists. It has the same properties as a spamtrap
hit: it is unsolicited, the detection method is objective and it does not
involve human intervention or judgment. SPF failures are not definitive and
can easily result from misconfiguration or forwarding problems, so it does
not lend itself well to automated reporting. Automated reporting means very
fast addition to lists that other sites can use as a basis for rejection.
This really tilts the scales in the direction of legitimate mail and helps
stop spam runs in progress.
--
Seth Goodman