From: John Levine
Sent: Saturday, September 18, 2004 10:03 AM
<...>
My prototype does put a timestamp in the signature, ...
That will prevent replay of old signatures, but not of fresh ones.
Correct. That's not a bug. That's what it's designed to do.
So you want to get replay attacks based on freshly harvested signatures?
That is a feature only in Microsoft lingo. When something is designed to
perform an undesirable action, most people call that a bug :)
In particular, BATV is NOT a way for recipients to verify the
authenticity of arbitrary senders.
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.
We'll have to disagree there, since the overhead required for sending
hosts to remember all the mail they've sent and to respond to
per-message inquiries is enormous, and trying to guess when a
signature has had "too many" bounces will cause both false positives
and false negatives.
The system you refer to above is an older design. The current scheme no
longer requires the sender to track any mail sent or the number of
validation requests, nor do the return-paths any longer have to be unique
per-message. We accomplish this by putting a message body hash in the
return-path. Since this is signed by the HMAC, it permanently ties that
specific message body with that specific return-path. The replay is foiled
by the recipient, who finds that the message hash does not match the one in
the validated return-path and rejects at the end of data. This is very low
overhead at both ends. Since it is stateless, validation results for
return-paths can be cached at both ends until the signature expires. It is
an HMAC validation via UDP for the sender and if the return-path validates,
the recipient does a body hash computation to check for replay. Trivial
forgeries can be rejected before data, and replays are rejected at the end
of data. Either way, no forgeries using signed return-paths that support
validation get through.
If you're trying to use PK bounce address signatures to let recipients
verify arbitrary bounce addresses, I agree there are cut and paste
problems, and complexity of trying to deal with them are also great.
Since you have to read the message anyway to see if it matches the
signature, I see no meaningful advantage of bounce signatures over
something like domain keys.
The system described above is, for all practical purposes, as strong an
authentication mechanism as DK. In fact, if the signing keys at the sender
are per-user, it gives a higher grade of originator authentication. The
advantages are that there is no key management system required, no public
keys in DNS or PKI and the computational load is orders of magnitude less
that any PK scheme. PK validation at the recipient is very compute
intensive. This system substitutes an HMAC validation for a PK signature
validation. In terms of overall complexity, network resources and
computational load, it's not even close.
--
Seth Goodman