From: John Levine
Sent: Friday, September 17, 2004 7:12 PM
The problem here is that the draft does not explain how it deals with
the cut and paste attack.
There is no cut and paste attack.
Due to trojaned PC's sitting behind MTA's that don't strip the return-path
signature, I'm afraid that is not a realistic assessment.
<...>
A bad guy could send you a zillion bounces to the same message (or
more likely, a buggy MTA) but I don't see that as a big enough threat
to be worth a large amount of mechanism to avoid. If it is a problem,
a simple band-aid that counts the amount of mail to each BATV address
and rejects mail beyond some per-address limit seems as effective as
anything else and doesn't need any support from standards.
I believe these were the same methods, which we worked with and have mostly
abandoned in SES, that led you to declare:
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Thursday, September 16, 2004 8:03 PM
To: ses-devel(_at_)codeshare(_dot_)ca
Subject: Re: [SES-DEVEL] SES patent
<...>
I've been on the SES list all along, but I concluded quite a while ago
that SES has gotten so complicated that it's not going to be practical
to use other than in toy systems.
Though we have worked out ways to do it, validation counting in a large MTA
array is not easy. Setting the threshold is a guessing game at best due to
the unknown forwarding relationships of the recipients. Putting in a
message body hash completely stops replay with very little extra overhead at
either end and makes tracking the state of individual messages unnecessary.
It also facilitates end-to-end validation by the recipient asking the sender
to validate the relatively short return-path via UDP followed by the
recipient validating the message body with the hash. This was not the
original goal of SES, either, but it has turned out to be a very welcome
side-effect.
My prototype does put a timestamp in the signature, but I do that
because I've noted that address scraping from the web is a major
source of spam targets, and that's a way to make scraping of old
archives less effective.
That will prevent replay of old signatures, but not of fresh ones. Since
the signature lifetime needs to be at least a week or so to allow for
temporary delivery failures to resolve, there is plenty of time to harvest
fresh return-paths.
In particular, BATV is NOT a way for recipients to verify the
authenticity of arbitrary senders. I agree that remotely verifiable
bounce address signatures are an interesting idea, but this isn't it.
I also happen to think that the only reasonable way to do them is to
wait for MASS to do its thing and piggyback on top of whatever key
distribution scheme it uses rather than trying to invent our own.
SES didn't start out with that idea in mind either, but it has become clear
it is a good way to do this at lower overhead than competing methods. It is
far lighter weight than PK schemes and has lower DDoS potential. It is
simpler than SPF as neither published records nor parser nor recursive DNS
lookups are required. The two return-path validation schemes we are playing
with for SES are a custom UDP validation service running on the MTA but
addressed through the domain MX and a "stunt" DNS server who's only task in
life is to validate these signatures. Both approaches require a
single-packet UDP validation request followed by a single-packet UDP
response. The computational load for the sender of creating an HMAC and
body hash and validating an HMAC is orders of magnitude less than creating a
PK signature. The results can be cached at both ends of the link to improve
performance. Similarly, calculating a body hash at the recipient is orders
of magnitude less effort than validating a PK signature, so it is a win from
the recipient's standpoint as well.
Including a strong enough body hash in the return-path and signing it with
an HMAC of sufficient length gives you more than enough forgery protection
for normal email, especially considering that the signature has a limited
lifetime. We have studied the cryptography enough to permit a sender to
easily determine how much forgery protection they get. They choose the HMAC
and message hash lengths according to their site bandwidth, signature
expiration time, assumed computational strength of an attacker (size of
zombie array) and likelihood of an attacker being able to succeed in a
chosen text attack or guess an HMAC before the signature expires. The
resulting formulae are quite simple.
Validation through signed return-paths also avoids all key distribution
issues and senders wishing to use this method don't have to publish
_anything_ additional in their DNS. This is a very simple scheme that has
some very powerful properties. Everyone has pretty much assumed that PK
crypto is the only way to do real authentication, but working with this
simple scheme has convinced me that is not really necessary. I think that
using signed return-paths for both forged null-sender protection and
originator authentication deserves serious consideration.
--
Seth Goodman