From: Michael R. Brumm
Sent: Saturday, June 05, 2004 3:57 PM
Seth Goodman wrote:
Well, this hasn't gotten rid of SUBMITTER, which was one of your goals.
That wasn't one of my "goals". Read the subject. The point of my
email was using ENVID was to prevent the insertion of forged
bounces if we use SUBMITTER.
This is correct. I misconstrued the content of the message to imply that
you were arguing to get rid of SUBMITTER, which you were not. I retract the
above statement and apologize for misunderstanding your post.
Compare this to straight SES...
I'd love to do this comparison, except examining SES is like
trying to nail jello to a tree. It seems to have a different spec
every day. Does it involve CBV (callback verifier)? What is being
signed? If just the originating address, what prevents replays?
Should it be done by the originating sender or the forwarders? If
the forwarders, how is it different from SRS?
I sure seem to see a lot of rah-rah postings about SES, but never
any decent specs or analysis. Consider something like this:
http://www.libsrs2.org/documentation.html
You ask a number of questions that have already been dealt with at great
length in the discussions of SES as a possible mechanism on this list and
SRS-discuss. For the benefit of those who have joined the list since those
discussions took place and those who did not follow the discussions in
detail, here are the answers to your questions.
1) "It seems to have a different spec every day."
SES is a work in progress, not a fully documented protocol with working
reference code and a pretty website. The original idea (by David Woodhouse)
was to universally sign all outgoing messages using the SRS format to
prevent forged bounce spam. It later was proposed as an end-to-end
verification system using CBV's.
2) "Does it involve CBV (callback verifier)?"
In the merged SPF-CID system that uses SES+SUBMITTER or SES+(reverse source
route), there are no CBV's. The SES signature is there to give airtight
forged bounce protection and nothing else.
As background information, we had been recommending, until recently, CBV's
as a mechanism to permit final recipient validation of SES-signed originator
addresses. This elicited a mixed reaction. Some people disliked CBV's and
provided solid technical arguments. Some people disliked CBV's for
philosophical reasons. Some people disliked CBV's for both technical and
philosophical reasons. Some people looked at it and felt the benefits far
outweighed the costs. The fact that two very large providers, Verizon and
PoBox both use CBV's somewhat deflated the argument that it could not scale
to large systems, but it remained a contentious issue and prevented us from
achieving a consensus.
Recently, Stuart Gathman and Greg Connor suggested an alternate method of
SES validation that involved running code on a DNS server that can validate
SES signatures. The DNS queries would be in response to exists macros in
the SPF record. This solution has great potential, but needs further
evaluation and has nothing to do with what Meng proposed as part of the
merged SPF-CID proposal.
3) "What is being signed?"
The originating address in MAIL FROM:.
4) "If just the originating address, what prevents replays?"
Prior to Meng recommending SES as a component of the merged SPF-CID
proposal, he asked if we had fully considered the replay attack scenario.
We hadn't, and the ensuing discussion considered the extent of the
vulnerability, proposed a number of possible solutions and evaluated each of
them. The rough consensus of these discussions was as follows.
i) Replay attacks are a problem only for a small class of sending accounts
that may send mail directly to spammers. These include promiscuous sales
accounts at large corporations that send replies to anyone and network
security/law enforcement accounts that send messages directly to spammers.
The vast majority of normal users are not vulnerable to this attack, since
they don't send mail to spammers.
ii) For those few vulnerable sending accounts, there are several simple
techniques to mitigate the vulnerability. The simple techniques cannot
remove the vulnerability entirely, but make it useless or a wide-scale
attack. The most practical simple measures were: using extended precision
timestamps to make each outgoing message timestamp unique, automatic
invalidation of timestamps that generated too many DSN's or CBV's and using
per-user hash secrets to limit the vulnerability to a single account.
iii) For recipients, the most practical measure is identifying known
forwarding accounts per user and rejecting forwarded mail from others.
iii) For vulnerable sending accounts, we did consider strong crypto methods
that signed the message body, but it was not practical to include the crypto
signature in MAIL FROM:. However, if complete protection against replay
attacks is required for particular vulnerable accounts, existing strong
crypto methods should be employed. The fact that all mail coming from those
accounts are signed using a particular crypto protocol should be published
in the domain SPF record. This will permit rejection of replay attack
forgeries at the end of DATA in case of lack of a crypto signature or
signature with the wrong certificate or if the MTA validates crypto
signatures and it does not validate. If the message contains the original
signature but the content has been altered and the MTA does not validate
signatures, the MUA should warn the user.
5) "Should it be done by the originating sender or the forwarders?"
Only originators sign the MAIL FROM: address.
6) "If the forwarders, how is it different from SRS?"
Forwarders do not sign the MAIL FROM:.
--
Seth Goodman