From: Shevek
Sent: Sunday, June 06, 2004 1:25 PM
On Sun, 6 Jun 2004, Seth Goodman wrote:
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.
SRS-signing outgoing mails at the first hop is fine. However, consider
what happens if a forwarder sees an SES address. If it doesn't recognise
the address as SES, then it will deliver the mail, receive a bounce, and
send that bounce (a joe job) back to the sender.
Since the forwarder only "sees" the SES address in the return-path, I'm not
really sure what you mean so I'll try to guess. You didn't say if the
forwarder does SPF, so let's assume that they do. To get the forwarder to
accept the joe-job, the incoming message must pass SPF. For that to occur,
it must be sent as a forged forward from an MTA that will pass an SPF check.
This means they have to divulge their entire identity, but let's say they do
it anyway. They forge the original sender in MAIL FROM: and concoct headers
that will yield an extracted PRA equivalent to MAIL FROM:. Here is what the
SMTP commands look like coming into the forwarder, using reverse source
route format:
MAIL FROM:<@forger:SES0=HHHH=TT=user1(_at_)innocent-domain>
RCPT TO:<user2(_at_)forwarder>
The forwarder does an SPF check on the SMTP-client using domain "forger" and
the result is PASS. The forwarder then allows the SMTP-client to move on to
RCPT TO: and checks that the delivery address is real. Assuming it is,
forwarder then allows the SMTP-client to move on to DATA and extracts PRA,
which is, let's say, outgoing-05(_at_)forger, so that test passes and they
accept
the message. Assuming that user2(_at_)forwarder has set up their account to
forward to user3(_at_)target, forwarder then sends the message as follows:
MAIL FROM:<@forwarder,@forger:SES0=HHHH=TT=user(_at_)innocent-domain>
RCPT TO:<user3(_at_)target>
Since the forwarding account was set up by the user, we can assume the
destination address at "target" is valid. This forgery will get delivered,
but there will be a clear audit trail to the source. If the end user's
mailbox stays full for long enough, "target" will eventually give up on
delivery and send a DSN back to the originator as follows:
MAIL FROM:<>
RCPT TO:<SES0=HHHH=TT=user(_at_)innocent-domain>
Unless the SES signature is valid, it will be rejected by innocent-domain
and there is a clear audit trail to the source. Either way, the forger gets
caught. This forgery mechanism is not unique to SPF+SES, and as shown
below, it also works for SPF+SRS.
If it does recognise the
address, then it presumably has to verify it, otherwise it's possible to
joe-job anything that looks like an SES address.
Just as in SRS, the second hop forwarder does not validate the message
originator. Each hop can only validate the previous hop MTA. That is a
fundamental limitation of SPF. Yes, you can joe job any domain, with or
without an SES-signed originating address, but you have to do so using an
MTA that passes SPF. This means you have to expose your full identity, not
just your IP. You will quickly lose both your domain name and IP, but
nothing will stop you from initiating the joe-job. This has been a
fundamental property of SPF since the beginning, and SPF+SRS is just as
susceptible to it. SPF does not prevent joe-jobs, but it does force anyone
who commits one to do it through a traceable domain.
Here's how "forger" would commit the same joe-job using SRS:
MAIL FROM:<SRS0=HHH=TT=innocent-domain=user1(_at_)forger>
RCPT TO:<user2(_at_)forwarder>
"Forwarder" will accept the message and the result will be similar to that
above with one exception. In the case the final delivery is not possible,
"target" will send a DSN to "forger", who will either reject it or accept
then drop it. The joe-job does not stop until "forger" loses their domain
name and IP. If you don't like this behavior, and I certainly don't, the
only answer is end-to-end verification. We have a _chance_ of doing that
with SES via DNS, but that is so far just an idea and not necessarily
practical, though some very good minds think it is. There is no chance of
doing end-to-end validation with SPF+SRS. If for no other reason, that
makes the choice pretty obvious to me.
This validation is considerably more complex than SRS since it involves
getting the signature data from the originating server (DNS, or
whatever)
every time a mail is forwarded. This does not work for users on dialup
clients who do not have a place to publically post DNS information.
Since we don't do validation, this isn't an issue, but I'm surprised you
bring this up at all. A fundamental limitation of the SPF implementation
that has been around for months is that clients on dialup lines with dynamic
IP's have to find some other arrangement to send their mail besides forging
the return-path. This has nothing to do with SES, SUBMITTER or SRS and
remains a problem for any method of forwarding used with the present SPF.
The originating address in MAIL FROM:.
4) "If just the originating address, what prevents replays?"
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
This isn't true. Replay attacks are a problem for any SES address which
appears on the public internet. A lot of email addresses appear on the
public internet. Therefore a lot of email addresses become vulnerable to
SES replay.
Just like SRS, MTA's that implement SES as part of SPF will strip the crypto
information out of MAIL FROM: when they create the Return-Path: header. If
an MTA receives a message for a legitimate user that you sent, and said MTA
fails to strip the crypto information from Return-Path:, what of it? That
party is not a spammer and is not going to abuse you. Mailing lists already
retain the From: address instead of using MAIL FROM:, so they are not a
problem. If not through a mailing list, how does an SES-signed return-path
get on the internet in a place that spammers can harvest it? The short
answer is, it can't. Just like SRS, the only way for a spammer to get one
of your signed return-paths is if you send him email directly. As you have
pointed out many times: if you don't want spam, don't email spammers.
Remember that the utility to a spammer of a single SES address is
immeasurably greater than the utility to the spammer of a single SRS
address. A single SES address can be used to send any number of spams to
any number of recipients. A single SRS address can be used for a limited
time only to spam the original sender only.
A spammer has no opportunity to harvest signed return-paths from users that
haven't directly sent him mail. For those who might send email directly to
spammers, use the measures I recommended to mitigate the problem.
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.
[SNIP]
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.
Now SES also has to publish a policy for how these signatures are to be
verified, whether they must checksum the body or just the headers, ...
this rapidly becomes more complex than anything previously envisaged.
This is completely false. SES does not publish anything. I simply
suggested, as an optimization, that _if_ an SPF record included a parameter
that said "all legitimate mail from this domain bears an SES signature",
recipients could reject any mail claiming to be from that domain that did
not have one. The same is possible, and probably advisable, for any of the
common strong crypto mechanisms, like S/MIME or PGP. This is not
complicated and more importantly, SES works perfectly well without it.
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:.
This leaves them open to the 5 party attack documented at
http://www.libsrs2.org/srs/srs.pdf.
SRS is also vulnerable to the 5-party attack and that doesn't seem to be of
much concern. Why is it here?
We still need a single coherent document describing this protocol. It
needs to be stated, for every possible case of replay, by any party, to
any party, why it is possible or impossible.
As soon as Meng can achieve a general consensus among the parties he is
negotiating with, I agree that needs to happen. Until then, we all have to
debate the ideas as they are expressed, even if they are not formal enough
to satisfy all tastes.
SES gives the spammer something he didn't have before: An address with a
signature attached saying "This mail is valid." It also requires
modification of every MSA, MTA and MUA, while SRS requires only
modification of forwarding MTAs.
SES is relatively simple to implement and gives the implementer immediate
protection against forged bounce spam. SRS is relatively complicated and
does not give anyone protection against forged bounce spam. If you want
protection against forged bounce spam, SES is the easiest way to get there.
The recent informal poll that Meng conducted showed what we've feared all
along but didn't want to say publicly: SRS is seen by most parties as
undesirable and hindering SPF adoption. I'm sorry if you consider that
result distasteful or wrong, but please don't shoot the messenger.
This is not good.
Ditto.
--
Seth Goodman