ietf-822
[Top] [All Lists]

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

2005-03-04 13:42:19

In <3ded1f56842d928785cf18567f532025(_at_)cs(_dot_)utk(_dot_)edu> Keith Moore 
<moore(_at_)cs(_dot_)utk(_dot_)edu> writes:

all of the authentication schemes I've seen suffer from one or both of
these problems:

-  trying to do more than is reasonable for that particular approach

This seems to be a pretty subjective criteria.  I suspect that
reasonable people can disagree on what might be considered
"reasonable" for a particular approach.

yes, there will be some disagreement, but the opinions will often
cluster in one general area, and you can get rough consensus on them.
this does require engineering judgment.  it's not as if, for instance,
there are objective criteria for how many DNS lookups are too many to
use to validate an email address, but you'll get general agreement
among most knowledgeable folks that there's a limit to how many
lookups is reasonable, and those opinions will cluster around some
compromise number.

Two comments:

First off, the SPF spec was developed in just such an open and mostly
by consensus manor.  However, you ignore the possiblity that instead
of one cluster, you may have several different clusters.

Secondly, there is an objective criteria for the number of DNS
lookups: "The number of DNS lookups must be limited to the point that
SPF can not be effectively used for DoS purposes".  (Most seriously,
on third parties.  That is, not the owner of the domain with the SPF
record, nor the receiving MTA, but someone that the SPF record
targets.) 

One of the changes I made to the current draft is to impose limits
first added to my libspf2 implementation, about a year ago.  This *is*
a significant change to the draft since most SPF implementations
didn't not have these limits, but I consider such a change important
enough to justify the breakage that happen.  I think it is simply
unacceptable to have a standard that allows for DoS attacks on third
parties. 


-  trying to retroactively change how the mail protocol is used, or to
restrict future use of the mail protocol such that valid use cases
will no longer work

Well, current SMTP specifications allow for anyone to use any domain
in either the rfc2821 identities, or any place in rfc2822.  All
authentication schemes intend to change that.

it's tempting to respond that all of these authentication schemes are
therefore "broken".  but that's so simple a statement that it's likely
to be taken the wrong way.

part of the problem is that none of the existing fields in either SMTP
or [2]822 are intended to hold an authenticated ID of the originator,

Agreed.

with the possible exception of Sender, even that one isn't well
defined enough (or consistently implemented enough) to use.  and for
every one of those fields there are numerous valid use cases for that
field not being an authenticated ID for the originator, even though
you might want to authenticate the message.  we simply don't have a
field for that purpose defined at present.  various authentication
schemes try to work around that by constraining or overloading
existing fields.  the goal in doing so is to ease deployment, but what
it actually does is limit the scheme's applicability.

The reason for wanting to authenticate the fields isn't just "ease of
deployment".  I don't even think that was the primary reason.

Many domain owners want to have some control over how their domain is
used, and many email receivers wish to listen to the domain owners.
Both snail mail and email allow anyone to put any name as the return
address and on the letter head of the letter.  Sometimes this isn't
abusive, but sometimes it is.  Making a letter/email look like it
comes from "Big Bank" when not authorized by "Big Bank" can get you in
legal trouble.  With email, and the various email authentication
systems, "Big Bank" can take technical steps, instead of just legal
steps, to prevent this.


-wayne


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