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. 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.
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.
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.
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.
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.
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.
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.
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.
This is not good.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/