ietf-mxcomp
[Top] [All Lists]

RE: How is SPF different from RMX?

2004-08-04 10:30:36

On Wed, 4 Aug 2004, Hallam-Baker, Phillip wrote:

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.

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  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.


<Prev in Thread] Current Thread [Next in Thread>