On Sat, 4 Jun 2005, Dave Crocker wrote:
Even with John's posting to correct this mis-statement, it appears the
point was missed: BATV places the state information into the message.
It does NOT require the BATV creator or interpretor to retain state
externally.
My statement was exactly correct - SES and BATV work almost the same
way and suffer from the same problems. Both allow for alternative
algorithms too so one algorithm could require retention of state on
the origin server (never on intermediate sites as far as I know,
although SRS appears to do just that...) and one would not but suffer
from other problems.
Let me go through this slowly:
I. How this all works
Both SES and BATV add an encryption signature into RFC2821 MAILFROM
(bounce) address. Right now both are using symmetric key cryptography
so I'll focus only on that and not on any proposed public key scheme.
I think (though BATV did not specify) both SES and BATV are using HMAC
symmetric key cryptographic algorithm, though really actual algorithm
does not make any difference.
The signature added is a hash of the data which would always include
actual email address for RFC2821 MAILFROM and may also on other data.
These other data can be:
1. Time of when signature was added
2. HASH of actual email body
When time is added, the timestamp would also have to be added as separate
data in RFC2821 so that signature could be verified (its possible though
to use time from "Date" header field)
The difference is that SES provides for public verification server. So
for SES a system that wants to send a bounce, would when it sees the
signature call this server and ask - IS THIS SIGNATURE CORRECT?
If answer is no, it would not send a bounce.
For BATV, the bounce is always sent and then when its received, the
original sender system (that added signature) would try to check if
signature is correct and if not would discard the bounce to /dev/null
II. Problems with MAILFROM signature approaches
The data from RFC2821 is not 100% private for mail system interaction only.
It is seen by users in Return-Path field ans some of the locations where
email come to are archived in real-time. It is sometimes revealed in
trace data, in particular some mail MTAs add it to Received as part of
nowhere defined "envelope-from" clause or sometimes in (envelope-from ..)
comment. It is required part of the Received-SPF trace header field, it
maybe data that goes into Redirected trace field. It maybe data that is
found in Authorization-Results field. Entire trace data is publicly
available for mail lists and almost all mail lists keep public archives
with majority of the archives providing access to raw message data as well.
So any signature data used there should be considered to have become
publicly available info once message has been sent and is subject for
use in replay attack (replay means that somebody, probably a bad guy,
would create a message and use somebody else's MAILFROM signature).
It should also be noted that the bigger number of MAILFROM signatures
sent that are substantially the same, the easier it is to find in public
places and use that for replay attack.
1. MAILFROM signature is signed hash of MAILFROM address
Totally open to replay - just find somebody else's full MAILFROM address
with signature and start sending messages with with the same address
and then all bounces would come to the victim.
However one form of protection that could be used is changing private
key often, say every day and then if signature is received that is not
signed by one of the last 5 keys used, it can be considered invalid.
This is almost the same as MAILFROM with timestamp described below,
just that timestamp is not used and is simulated by changing keys.
It suffers from the same problems plus with timestamp each signature
would be unique where as with changing keys they would be the same
for entire day.
2. MAILFROM signature includes timestamp
In this case replay attack would only be possible within email delivery
time period after signature was sent (usually considered 5 days).
However I do not believe that it would be very hard to create a program
that would look at various mail list and similar archives and find address
for spammer use within 5 day period in automated manner. So all the same
problems as classic replay are all there.
Possible protection can be achieved by having sender keep track of
bounces received and if more then one or two are received for same
message, all other bounces would be rejected. This does mean keeping
database on the sender side - but its only database of bounces and
not all mails sent.
3. MAILFROM signature includes hash of message data
In this case each message signature is guaranteed to be unique, which
is good (but same uniqueness can be done with timestamps above). The
problem is that to be able to verify the signature entire message data
or hash of it would have to be known. This gives several options:
a. Include hash of message as part of addition data in the MAILFROM
Unfortunately the maximum size for MAILFROM local part is 64 bytes
and with signature already being cryptographic data, it takes most
of it and including additional cryptographic hash (SHA1 is 20 8-bit
data bytes and 32 for BASE32 representation which would be needed
for MAILFROM) is not much of an option.
b. Keep track of the hash on the server that added the signature and
only include in the MAILFROM unique id of the database record or
include in the database entire MAILFROM record with signature.
c. Do MAILFROM signature verification only when message DATA is available
For BATV option c is possible (preferred?) since bounces are dealt
with after being received, but the problem is that bounce messages do
not necessarily include original message data intact: sometimes bounce
received would only say message has been rejected without specifying
as to why, sometimes the data would include only original message header
but not the body, sometimes it would be only one body part, etc. So
I do not believe that this is viable and workable solution for BATV
in current email environment.
For SES, the option c is not possible since SES does verification at
the time of MAILFROM as part of SPF check. They do appear to try a,
but run out of space in too many cases... So only viable option is b
which is to keep local database of all messages sent and hash or
signature that ended up as a result. But as I've already noted if
you keep local database, why bother with cryptography as one can just
randomly generate long string, attack that to MAILFROM, i.e.
"rrrrrrrrrrrrrr-real(_at_)user(_dot_)com" and put "rrrrrrrrrr" in local
database
and keep track of bounces that come back and check if its valid.
This also is still open for replay attack as one can just take this
bounce from public location and attempt to send messages like that and
it would validate. To deal with replays, the verifying server would
have to keep track of bounces, most likely in opposite way to what
I described in 2 as instead of keeping track of bounce, when bounce
is received, its unique rrrrrrrrrr is removed from the database and
so it would no longer validate.
However the problem with having to keep local database of all sent
messages is that its not scalable for when it needs to be deployed in
the environment with millions of messages sent per hour. So while
it may work for small personal domain, for large one it would not.
III. Summary & Conclusion
Of above the most viable option appears to be 2 which is to use timestamp
to guarantee uniqueness of MAILFROM signatures in all messages sent and
keep database locally for bounces that are received to deal with replays.
Additionally changing of keys often would also help in insuring
cryptography is not easily broken and allow for additional check to
restrict when signature is still considered valid.
SES people have lately been advocating #3 (include message signed data
in signature) which I think is total mistake and would make their
solution largely unworkable in anything but a small test environment.
If comparison is between SES and BATV with both creating signature
with only MAILFROM and timestamp (BATV is then basicly same as SES
but without public access to verification server), then SES is better
because it offers an option to remotely verify if signature is correct
and that verification can be easily integrated with SPF and so allow
all bounces to be discarded where as with BATV bounces would all be sent.
Additionally I think in order to ensure replay attacks can not easily
be done, it needs to be mentioned that mail servers adding trace data
SHOULD only include in that original localpart and note entire MAILFROM
signature, then finding the signature to use for replay would not be
easy in automated manner.
The above requires awareness of the signature system and format for all
MTAs (and not only of the sender as BATV has been saying) and that is
why I have strongly advocated some months ago that BATV, SES and SRS
(which could also suffer from replay attack) all agree on common syntax
but unfortunately BATV and SES people can't stand each other and their
personal dislike is going to be downfall for all of their inventions.
BTW - in my personal opinion both BATV and SES could/should be merged
and become one technology with some people running public verification
server for SPF and some (those who do not support SPF) not running
it and doing verification locally for received bounce.
For further technical reference see:
BATV - http://www.mipassoc.org/batv/draft-levine-mass-batv-00.txt
SES - http://ses.codeshare.ca/files/Working_SES_Format_Definition_16.html ;
Therefore, the statement: "the same is also true for BATV" is incorrect.
That statement was correct. And I dare you to tell me that I dont understand
the technologies or that I'm seriously wrong in above description and
evaluation.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg