Subject: RE: How is SPF different from RMX?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 4 Aug 2004 09:38:23 -0700

> On Wed, 4 Aug 2004, Hallam-Baker, Phillip wrote:
> >
> > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html
> > > http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html
> >
> > These are pointers to issues that have already been raised, are not
> > considered critical and in any case fall far short of the claims
> > made by Dean of Death of the Internet: News at 11.
> 
> Not critical?! I'm expecting deployment of SPF and Sender-ID to cause
> significant problems for my site, and I neither publish nor 
> check these
> DNS records. A protocol that causes problems for sites that do not
> participate is seriously flawed.

Critical means that it will take down the net.

What you describe is called inconvenience. That is very different.

Sysop inconvenience is one of the motivations for MARID. It is much
easier to get onto the whitelist of a major ISP if you advertise your
IP addresses through MARID and it is much easier for them to
maintain their lists.

If you do not participate in MARID it has no effect on your 
infrastructure. Other people may not be willing to accept your mail 
but that is already a major issue for most ISPs.

> Of course the fundamental reason for the flaw is obvious: a trivial
> failure to apply the end-to-end principle.

End to end security has been widely discredited as brittle and
undeployable. It is a great objective but attempting to insist on
end-to-end or nothing has empirically been an abysmal failure.

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Aug 2004 18:30:34 +0100

> end-to-end or nothing has empirically been an abysmal failure.

CSV and BATV have the same deployment and scaling characteristics as
designated sender protocols, but they do not have the same problems.
This is because they both work within protocol layers, not across them,
and are end-to-end within those layers.

CSV works at the single hop MTA-MTA layer, and authenticates identities
that are relevant at that level: IP addresses and host names. STARTLS
work here also (but has poorer deployment characteristics). The end
points happen to coincide with the end points of the TCP connection.

BATV works at the envelope layer, where the end-points and identities to
be authenticated are email addresses. In particular note that error
handling at this layer is by means of the return path, which does not
change through alias-forwarding. Any security protocol at this layer
should have the same coverage as the error handling (i.e. the same
end-points) which is obvoisly the case for BATV because it embeds a
security token in the error reporting address.

The next layer up is the message header which has wider end-points because
certain kinds of forwarding (mailing lists and re-sending) preserve
important parts of the header whilst replacing the envelope. DomainKeys
works at this layer.

Finaly there's the message body which has yet wider end-points because of
encapsulation forwarding (message/rfc822 MIME parts etc) and other copying
around. PGP and S/MIME work at this layer.

The problem with designated sender schemes is that they mix up the first
two layers, assuming that the end-points are the same and that identities
at one layer can be used to authenticate identities at another. Therefore
they are broken as designed.

If you apply the principles of security design correctly then you get much
stronger guarantees. For example, BATV can guarantee to a recipient that a
message was submitted by a particular person (or someone who knows their
password), whereas designated sender schemes only tell you that any of
thousands of people able to use an MTA sent the message -- they don't even
authenticate the domain properly! This is also why BATV can stop
collateral spam dead without co-operation from anyone else, whereas
designated sender schemes only stop it as a second-order effect and are
powerless against first-order forged bounces.

How I plan to provide proof of SMTP AUTH to the final recipient:
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/cam.txt

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.