SPF and the need for SRS

On Sat, Feb 28, 2004 at 05:29:10PM +0100, Hadmut Danisch wrote:
| 
| - If the message was forwarded, bounced, mailing-listed,...
|   the given sender address will not help us in locating the 
|   domain taking responsibility. Bad. We need a different way 
|   to locate. That's the problem we 
|   need to solve.
| 

The problem SRS is trying to solve is twofold.

First, SRS is needed because SPF and other LMAP proposals that use the
return-path as the subject of authentication will break the forwarding
scenario.  SRS rewrites the return-path to make the forwarder compliant.

SRS wants to preserve the original sender address in the rewritten
return-path, because some forwarders place a value on ensuring that the
original sender receive nondelivery notifications, and I would like to
accommodate them.  SRS wants to do this securely, so that the reverse
delivery path does not become an open relay.

Similarly, the problem SPF tries to solve is twofold.  SPF wants to
enable forgery detection based on the return-path, so that forgeries can
be detected before DATA.

First, that means legitimate mail from a domain needs to receive a
positive result from SPF: in this form, SPF works as a whitelisting
mechanism when the sender domain is known to be reputable.

Second, SPF wants to stop joe-jobs.  As a corollary, it must be possible
for a domain that never sends outbound mail to announce this policy.

| 
|   The second way is to give it already in the envelope. But if you
|   agree to modify the envelope and rewrite the sender's address, then
|   what's the point in building such artifical addresses which actually
|   do not exist? What if a mail is forwarded five times? No size limit?
|   Sender address of 300 characters?
| 
|   And what if the original sender's address is admin+web. 
|   How would you parse admin+web+ann correctly? Is this
|   (admin+web)+ann or admin+(web+ann) ?
| 

I agree that SRS is a horrible hack, but the SRS community are working
on ways to make it more palatable.

There are a few specific implementation goals:

i)   the original sender should be preserved where possible, to allow
     receiver-side whitelisting
ii)  we want to avoid escaping schemes
iii) multi-hop forwarding should not lead to O(N) localpart growth
iv)  case insensitivity
v)   the reverse direction needs to be protected from open relaying.
vi)  an attacker should not be able to cause an SRS relayer to send
     email to a third party domain.

|   If you agree to rewrite the envelope sender, then simply use
|   the correct e-mail address of the responsible forwarder. Like
|   proposed in the RMX drafts.

This does not meet the first goal of SRS, allowing the original sender
to receive nondelivery notifications.

| 
|   If you don't want to rewrite the envelope, then all we need to do
|   this much more easier is to just add a header line like
| 
| 
|     RMX: somedomain.com
| 
| 

In these kinds of discussions, I have always found the phrase "all we
need to do" to be a red flag.  There is no "we" --- there is, instead, a
diverse set of constituencies, each of which may have strong feelings,
positive or negative, about any given proposal that requires their
involvement.  The mice also said "all we have to do is put a bell on the
cat".

For example, requiring all forwarders to rewrite the envelope with SRS
is a burden on the forwarder community (and on the web-generated email
community), but a tremendous benefit to other LMAP adopters because it
removes a significant obstacle to the LMAP model.

Requiring all forwarders to prepend "RMX: somedomain.com" is a burden of
similar scope though reduced magnitude.

The end-to-end LMAP model assumes that legitimate mail is always sent by
a domain's designated senders.  If forwarders and web-generated emailers
play along, this model comes much closer to reality (or rather reality
comes much closer to the model).  Either eway, it becomes much more
powerful.

| If I am correct and the given security problem is to just locate
| the domain which is willing to take over responsibility, then please
| explain why we need to use such a complicated and error-prone
| rewriting scheme, requiring changes in all MTAs. 

I define sender responsibility as the willingness to accept bounces and
do the right thing with them.  If it is possible for an attacker to
launch a joe-job on a third-party domain, then the attacker has not
really taken responsibility for those messages.

I define author responsibility as making a verifiable assertion that the
content and authorship of a message belongs to some sort of persistent
identity.

These are different goals.  I believe it is unwise to conflate them.
The first can be solved by designated sender means.  The second can be
solved by cryptographic signatures.

| If I am not correct and the problem is a different one, then please
| state the problem you're trying to solve. 
| 
| 
| 
| Writing perl modules and designing web pages is fun, but a precise 
| statement of the problem to solve and an explanation why to solve it
| this way is more important.

I expect to have a formal writeup of SRS soon.  I believe it will be
useful to all the LMAP/return-path schemes, RMX, DMP, FSV, and SPF.

It will describe in formal terms the problem(s) we are trying to solve,
the ways to solve them, the attacks that are possible on those first
approaches, and the mature approaches that solve those attacks.