CSV BATV (CLEAR) DK IIM (MASS)

On Tue, 2004-12-07 at 10:58, David Woodhouse wrote:
> On Tue, 2004-12-07 at 12:39 -0500, Alan DeKok wrote:
> >   But do they do the same thing?  I keep seeing statements like
> > "proposal X doesn't break forwarding like SPF breaks it".  But when I
> > look at proposal X, most of the time, it doesn't do MAIL FROM
> > checking, but something else.  So the comparison is unwarranted.
> 
> All proposals are different in their details; the important thing is
> what they can _achieve_. Take CSV and SPF, for example. Of course the
> details vary, but in practice they do exactly the same thing. Consider:
> 	MAIL FROM:<[email protected]>
> 	From: [email protected]
> 
> Precisely because SPF validates only one hop, it's achieving no more
> than CSV is. The recipient can look up how much they should trust
> 'forwarder.org' but you can't really tell if the message _really_ came
> from you.
> 
> DK is similar but it uses the RFC2822 address of the most recent sender.
> It's still achieving basically the same thing -- a validated name of
> some kind, which you're expected to look up in your reputation database.
> 
> SES does actually validate the MAIL FROM: address, and it survives
> traditional forwarding.
<snip>

A reference for SES is at http://ses.codeshare.ca/files/ses_proposal.pdf

The CLEAR wg http://www.mipassoc.org/clear/

Are proposing use of BATV that uses a slightly different encapsulation
of this extended information.  Standardizing on this encapsulation is
desired.

A reference for BATV is at http://mipassoc.org/batv/index.html

This different syntax (SES like), as proposed by William Leibzon for
BATV, was addressed by Tony Finch and extracted as follows from the
CLEAR archive:

> Consider a site that does thorough verification of email addresses,
> such that all BATV addresses are known to be valid and only appear on
> messages sent by the address's owner. Say that whether BATV is used is
> configurable per user. (This is similar to the deployment I am working
> on.) The victim has BATV turned on and the attacker has it turned off,
> so the attacker can use untagged return paths. The recipient knows a
> bit about BATV and assumes that a message with a return-path address
> that is tagged is actually from the apparent sender.
> 
> So if the recipient gets a message starting
> 
>         Return-Path: <batv=VALIDBATVTAG/victim@domain>
> 
> they correctly infer that the message was sent by victim.
> 
> However if they get a message starting
> 
>         Return-Path: <attacker+ACTUALLYALOCALPARTSUFFIX/victim@domain>
> 
> and carelessly fail to eyeball the start of the address, they might
> not notice that the message was from attacker not victim.
> 
> This is a minor human factors problem, but it's still a security
> consideration.

As an additional note-

Due to wildcard problems, SPF is unable to defend a domain as an abuser
could exploit existing records to defeat policy statements asserted
within SPF.  With there also being a lack of agreement which domain
referenced within a message should be checked, even assuming a check is
made at every MTA node, there can be no assurance the domain asserted by
the recipient as definitive is valid.  Should SPF ever be used as a
basis for reputation, there will be a great deal of effort needed to
sort out the resulting confusion and damage.

http://mipassoc.org/clear
http://mipassoc.org/mass

CLEAR and MASS are attempting to create relatively safe and less
disruptive solutions for the immediate need to authenticate an
accountable name for the mail channel.  SPF only offers authorization
(unfortunately easily spoofed or defeated), but never could it be said
that such domain has been authenticated as actually sourcing the abuse
detected through the results of SPF.

Although a provider may offer to authorize their servers for a domain
with SPF, the risks associated with respect to miss-applied reputation
will be endured by the domain owner.  The machine that has been
compromised by a security breach is not located by such an SPF based
reputation service.  The name that is important is the name of the
administering domain when dealing with security.

The provider instead should be offering to implement BATV as an
immediate solution for the spam bounce traffic that is really the
driving motivation for SPF I suspect.  This is relatively low risk for
the domain owner.  A few adjustments are still needed for this scheme to
prevent a few glitches.  Hence the need to standardize on the
encapsulating syntax.

-Doug