spf-discuss
[Top] [All Lists]

RE: "SPF Sender Authentication Deployment Recommendations" draft

2005-01-09 12:33:04
Mark [admin(_at_)asarian-host(_dot_)net] wrote:
Here is my second "SPF Sender Authentication Deployment
Recommendations" draft.

Alright, now I finally manage to comment on it.

[...]  I think it should not come as a surprise that I lean towards a
rather "classic" model of SPF + SRS. Especially so, since, imho, crypto
based solutions still have some major issues to overcome, where SRS
already offers an answer.

Define "crypto based".  SRS also uses cryptography in one of its forms.
But I agree that SRS is a good solution that should be "easy enough" to be
generally implemented.

The term "cryptographic" probably misses the point, perhaps "payload" (or
"content") authentication, as opposed to "transport" authentication, would
be better.

There are those who believe section 4a ("SPF and Sender ID") should be
more of a political statement. As you may know, I have never much been
in favor of that; for one, because I think saying things like "Microsoft
stole our SPF records" or something similar, tends to make one look
'childish' very soon -- even though it may be true. I like a more
cut-and-dry, factual statement. But if the SPF community rather see a
more political statement, I will accomodate that desire, of course --
no hard feelings. :)

I don't want a political statement just for the sake of it.  What I want
is a statement saying that...

  - using SPFv1 records for RFC 2822 identities isn't what they were/are
    intended for, both on a conceptual level and on the level of the
    millions of records already published,

  - the SPF project is not willing to concede this repurposing to
    Microsoft, i.e. the SPFv1 draft will not be adjusted to acknowledge
    the need for extra v=spf2 records, and

  - any complaints regarding the supposed brokenness that result from
    misinterpretation of v=spf1 records should be directed at Microsoft,
    i.e. SPF works correctly if used properly.

If a statement that makes all of these points, comes over as political to
some people, then so be it.  It might be most effective to make this a
separate statement from the one we are discussing here.

------------------------------------------
SPF Sender Authentication Deployment Recommendations

Please give a clear definition of the scope (AKA an abstract) of your
document.  That is, try to summarize in one or two short sentences what
its point is.  Is it about "SPFv1 vs. Sender-ID/PRA"?  Is it supposed to
be an SPF project equivalent to Meng's MAAWG whitepaper[1] (which
essentially would be a response to the Sendmail whitepaper)?  Or something
else?

1. Recommendations for Senders.

We recommend that Senders publish "v=spf1" records, so that Receivers
may authenticate designated, authorized mail servers. Senders should
publish "v=spf1" records with the MAIL FROM entity in mind. In the case
where Senders suspect "v=spf1" records to be erroneously interpreted by
Receivers as applying to either the MAIL FROM or elements of the message
header, the Sender may choose to publish a separate, void "spf2.0/pra
?all" record, so as to ensure that "v=spf1" records are only used for
MAIL FROM/HELO checks.

This is a very fuzzy position which seems to imply that the SPF project is
not willing to declare Microsoft's repurposing of SPFv1 records to be
technically wrong.  I'm not willing to imply that.  See my comments above.

SUBMITTER, if supported, supersedes the use of MAIL FROM. In those
cases, expect SPF checks to be done against SUBMITTER first.

SUBMITTER, when used under SPF, makes the return-path unprotected, see
section 4.2 of the SUBMITTER spec[2].  Ergo the misdirected bounces
problem is not solved, which makes SPF pointless in the presence of
SUBMITTER.

2. Recommendations for Mid-Points.

2a. Summary.

It is not what goes into your mail system which defiles your good name,
but what goes out. Thus it is the position of the SPF community, that
every Sender on the net take responsibility for his own "accountable
messaging space;" mail forwarders not excluded. In an SPF world, this
means that every outgoing message should bear the MAIL FROM stamp of
accountability for the relay in question. By consequence, we recommend
that mail forwarders do SRS on the MAIL FROM entity for mail in transit.

I like the essence of that.

Forwarding is relaying. Since forwarding hops lie, per definition,
outside the scope of Senders (as Receivers determine the forwarding
path), we therefore believe that forwarding, without SRS, "breaks"
IP-based Sender Policy -- in contrast to the belief that SPF "breaks"
forwarding. As such, we believe that the 'accountable' solution for the
forwarder lies in bringing each message in transit within the purview
of its own Sender Policy Framework, using SRS.

I like the essence of that, but don't like its tone.  It really should go
more along the line of:  "From a security and trust point of view,
forwarders are independent participants in the e-mail system.  Forwarders
must take direct responsibility for the mail they emit (that is, be
prepared to acquire bad reputation if they forward unwanted mail), or
every participant in the e-mail system, including spammers, can just claim
to be a forwarder and get away with it. #INCLUDE
LAST_SENTENCE_FROM_ORIGINAL_PARAGRAPH"

2b. Cryptographic end-to-end solutions.

s/Cryptographic end-to-end solutions/Payload (usually crypto-based)
authentication schemes/

Cryptographic end-to-end solutions count on mail in transit passing
through unaltered. Making modifications after a message is signed
(especially changes to the message body) breaks the cryptographic
signature. On outbound mail this happens, for example, when adding a
disclaimer or anti-virus blurb. The more pernicious instances, however,
we believe occur on inbound mail. Specifically with the use of industry
leading Mail Filter (Milter) software.

Milters operate early in the process of accepting mail: at the
SMTP-dialogue level,

(This is not generally true.  Some MTAs don't allow SMTP-time filters to
modify messages, i.e. messages can only be modified after they have
already been accepted and the SMTP transaction is completed, i.e. right
when the actual forwarding would take place.  Also, "Milter" is a
Sendmail-specific term as far as I can see.)

long before the altered message hits the .forward
file for relaying. They typically perform tasks like MIME-reformatting,
stripping off attached files with certain extensions, replacing inline
content with links to a local store, etc. As a result, come forwarding,
the modified message has already broken the cryptographic signature.
There are several ways out of this:

1): Never alter a message in transit.

The problem with the common use of .forward files, however, is that "in
transit" is really just a description of the overall, de facto route,
and does not denote a true separate state of delivery: a Milter, at the
RCPT TO stage of the SMTP-dialogue, only sees a local recipient (the
message only effectively becomes "in transit" as the result of a later
action).

Domain Keys, SES, and other cryptographic solutions, therefore, work

s/cryptographic solutions/payload authentication schemes/

great on a final, local recipient: a first-in-chain Domain Keys Milter
is expected to validate the cryptographic signature, after which point
other Milters can modify the message at will. As soon as the message is
relayed over a .forward file, however, it will have potentially passed
all other sorts of Milters, including popular ones that modify the
message.

Basically, a forwarded message is inbound mail, which thereafter becomes
outbound after all. Which means that, for p2p cryptographic solutions to

s/p2p cryptographic solutions/payload reputation systems/, or
s/p2p cryptographic solutions/content-based reputation systems/

work properly, neither Senders nor Mid-Points can modify the message --
Receivers allowing .forward files included! We believe that short-term
expectations in this area are unrealistic.

Caution!  Short-term expectations for the widespread, effective (i.e.
actually rejecting messages) deployment of SPF are unrealistic, too. :-|

2): Anticipate changes when signing.

We have taken notice of efforts in the cryptographic end-to-end solution
corner

Don't put alternative approaches into the "corner", we don't want to
belittle them. ;-)

to try and anticipate modifications made by mailing-lists, ISPs,
etc. We believe this to be the least viable option. Any such attempt is
bound to fail, and, for the time that it works, creates a massive and
unrealistic co-dependency between Sender and Receiver.

3): Re-sign the message.

Digitally re-signing the last step in the outbound delivery chain solves
the "breakage" of modified mail for Mid-Points; but, making it
essentially a new message, "breaks" the end-to-end concept of proposed
cryptographic solutions. In simple terms: the Receiver then still has
no way to determine the authenticity of the Sender's original message;
which was the whole point-2-point!

4): Do SRS.

In any such cases where a Mid-Point modifies a message "in transit"
(including .forward file Mid-Points, and not just specialized forwarding
services), the SPF community considers the forwarder better off doing
SRS than re-signing a message. SRS is much less computational, and
therefore faster and less of a resource drain. And SRS brings the full
benefit of IP-based Sender Policy into fruition.

I agree with the essence of the whole section 2.

3. Recommendations for Receivers.

3a. Fitness of purpose.

SPF "v=spf1" records are designed and published for software which
protects and operates on the MAIL FROM entity (and, under circumstances,
HELO/EHLO). Using SPF "v=spf1" records for any other purpose may or may
not conflict with Sender Policy. Specifically, the "v=spf1" language
does not cover other parts of the message transaction, such as
protecting From: or other visible headers. Improper use of SPF "v=spf1"
records may result in unexpected/unwanted behavior. In particular, we
point to the risk of having legitimate mail rejected.

We therefore recommend that Receivers not use SPF "v=spf1" records for
anything else than MAIL FROM and HELO/EHLO checks.

Very good.

3b. License encumbered technology.

The SPF community recognizes the existence of patent license encumbered
technology in today's market. It is the position of the SPF community,
however, that key components of the Internet infrastructure should
remain free of license encumbrances. As a result, we feel that license
encumbered technology, insofar as it overlaps with the use of SPF
"v=spf1" records, will hinder and/or conflict with the rapid, Open
Source deployment of SPF. We therefore recommend that Receivers only
examine SPF "v=spf1" records with algorithms that are, themselves,
unencumbered.

Caution!  We really don't want v=spf1 records to be evaluated with any
other algorithm than our official one.  Also, let's not be long winded,
let's just call PRA by name.

4. Overall Recommendations & Notes.

It is in the very definition of stopping forgeries that you disallow
certain things which were allowed before. If you sign messages, no one
thereafter must change them; if you forward, you change relay, and must
change accordingly.

"if you forward, you change relay, and must change accordingly"?  Huh?
Please rephrase that. :-)

Whatever you do, putting restrictions on something
means that sooner or later someone, somewhere, will have to give up
doing something which he merrily did before. If we're not willing to
take that step, then we're not willing to stop forgeries.

"If you're not willing to take that step, then you will sooner or later be
stepped on by those who are."  ;-)  (AKA, feel free to be a bit more
offensive.)

SPF Classic has already been deployed in many antispam and MTA products,
and currently enjoys the support of an estimated 1 million domains. We
therefore encourage continued development of SPF Classic in the email
industry. We furthermore encourage continued development and exploration
of other possibilities in the accountable messaging space, including,
but not limited to, Identified Internet Mail and cryptographic
solutions, like Domain Keys, SES, S/MIME, and PGP.

Ok.

4a. SPF and Sender ID.

As there has been some confusion on the relationship between SPF and
SenderID, we would like to clarify the relationship. While Sender ID
reuses existing SPF records to perform the PRA test, SPF Classic is not
Sender ID, and Sender ID is not SPF. The two technologies are
complementary, but they operate on different parts of the message and
serve different purposes.

I think this should be a separate statement.

Also, saying SPF and Sender-ID are complementary implies that we endorse
Sender-ID/PRA, which definitely is not a common position of the SPF
project.  s/complementary/related/

As a reminder, I think the most important thing to do would be to give
your document a clearly defined scope.  If that's what the title ("SPF
Sender Authentication Deployment Recommendations") already is supposed to
be, then I think the document is a bit undetailed.  It should be at least
as long as the Sendmail whitepaper, probably longer (see the MAAWG
whitepaper[1]).

With a clearly defined scope, I can give more comments.

References:
 1. http://spf.pobox.com/whitepaper.pdf
 2. http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-03.txt