From: Shevek
Sent: Sunday, June 06, 2004 5:14 PM
Points in reverse order:
On Sun, 6 Jun 2004, Seth Goodman wrote:
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.
If this is all SES is doing then why are we messing around with RSPs
and stuff? If it doesn't stop joe jobs, it doesn't stop phishing,
and by "forged bounce spam", I suspect you just mean mails with a source
of <>.
Yes, that's all it's being used for. I'm sorry if we have misunderstood
each other so badly. Let me try to address your questions.
The suggestion to use reverse source routes is simply an alternative to
creating a new ESMTP parameter, SUBMITTER (or RFROM/FRED/DAVE). It seemed
to several of us that using a deprecated but "required to accept" format
already ensconced in the RFC's was better than creating yet another ESMTP
parameter and dealing with its phased adoption. It also leads to shorter
MAIL FROM: lines and perhaps there could be some future utility in seeing
what hosts a message has been through before DATA (as in, "I don't want any
mail that bugger has touched").
Joe-job protection is not a function of SES, but SPF itself. As far as I
can tell, joe-job protection with a SUBMITTER system is neither better nor
worse, overall, than it was with SRS. To do a joe-job with the present
system, you pretend you are forwarding mail from the victim domain but you
have to validate who you really are to pass SPF checks. This same exploit
is available with SRS. You will get caught in both cases, but you still can
do it. This is something that is worth analyzing in more detail. If you
would like me to pull together another written description of the current
system that we can present to Meng to say, "Yeah, it's along those lines", I
would be willing to do that if it would help people to analyze and critique
the current ideas.
Phishing is another matter, and I am sad that the present proposal doesn't
do more in that area. I have suggested that a good start in this direction
would be to require that MAIL FROM: be identical to Sender:, if it exists,
or to From:, if Sender: does not exist. If MAIL FROM: retains its present
meaning as the originating sender and address for DSN's, I find it hard to
come up with valid situations that can't be easily handled some other way
that this breaks. I know that people don't like any restrictions, but the
present system is not working and a few reasonable restrictions are in
order. If we were to make this restriction, validating MAIL FROM: on the
first hop does validate either Sender: or From:, which the user sees. If
MAIL FROM: is not rewritten, or as long as the originator address can still
be extracted from the MAIL FROM: string, any system in the message path
could reject the message for that violation. Do you have an opinion on
this?
The simple explanation of SES is "A technique to restrict what addresses
may be mailed from a sender of <>." So K.I.S.S. It's this simple form in
which I support SES, and no other. The other stuff is all unnecessary
complication.
There is no other stuff at present. Meng did not propose to use CBV's to
validate the originating addresses, though any MX that implements SES will
respond properly to a CBV. Many people have expressed displeasure with the
fact that two major services currently use CBV's to validate original
senders, and perhaps they will no longer find it necessary when SPF is
adopted. That is up to them. At least this won't break their CBV's.
Several of us have discussed the _possibility_ of using SES in conjunction
with modified DNS servers to validate SES addresses through a DNS query.
Such a query would occur due to the presence of an exists macro in an SPF
record. _If_ this turns out to be practical, it would be a method for a
final recipient to validate the claimed originating address in the presence
of a forwarding site. Consider this stuff as blue sky thinking. I hope it
works out, but it may not and it has no bearing on the current merged
SPF-CID proposal.
What Meng has proposed including is simply your appropriate use of the KISS
principle above. Originating senders use a MAIL FROM: of the form:
MAIL FROM:<SES0=HHHH=TT=local-part(_at_)domain>
When the MX for that site receives a null-sender message,
MAIL FROM:<>
RCPT TO:<SES0=HHHH=TT=local-part(_at_)domain>
it checks for the presence of an SES address, that the timestamp is not
expired, that the local address is valid and that the hash verifies. If any
of these tests fail, it rejects the message before DATA. Destination
gateway MTA's strip the signature out and prepend the
Return-Path:<local-part(_at_)domain> header so no end user ever sees a signed
address. That's all it is.
Their motivation appears to have been that switching to a SUBMITTER system
made them more vulnerable to forged null-sender messages (I'll stop using
the term "forged bounce spam", as that seems to have been misconstrued) and
this is a relatively painless way to stop it. In fact, it's a useful
technique even without SPF, without SRS or with SPF+SRS.
As I pointed out above, this SMTP sequence is indistinguishable from a CBV.
As far as I know, no one is currently advocating using CBV's to validate
originator addresses as part of SPF. I don't plan to advocate that in the
future, as the idea was unpalatable to a large enough number of people that
it would be pointless. If it's not part of SPF, it probably won't happen,
so it will just be used to reject forged null-sender messages, as you
surmised above.
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.
It's barely formal enough to support discussion.
I would also like to see a little more written down, but I have no control
over that.
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?
SRS is not vulnerable to the 5 party attack. Read the paper. Please.
That is news to me. My memory could be totally wrong, but I thought the
last time I read your paper, it showed that SRS was vulnerable to the
5-party attack. I will read your updated paper and try to go through this
scenario.
In any event, is it of any significant concern that a 5-party attack is
possible, if that is indeed the case?
--
Seth Goodman