Subject: Comments on marid-core-01

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Jul 2004 14:14:45 +0700

Herewith my "review" comments on marid-core-01.  Given the history

    Quoted text, from the specification, is indented)

My comments follow the quoted text and begin at the margin.

    MTA Authentication Records in DNS

The described mechanism does MTA authorization, not authentication.

If this is an authentication mechanism, it needs to explain how and
what it authenticates.

Given the confusion on the mailing list, this specification needs to
list an acronym for referencing it.  I assume that this is the
document folks mean when they say Sender-ID, but whatever the right
acronym, please list it.

   1. Introduction

   In order to avoid further fragmentation of the Internet email
   system,"

There is nothing in the document that makes a case that Internet mail
has become "fragmented" or that this particular technique will freeze
the fragmentation (though I suspect you mean "eliminate" or somesuch.)

The goal of the technique is to detect certain kinds of forgery and
those kinds of forgery are popular right now. This is an inherently
legitimate goal, so the disaster language is not needed.

I think the document, as a specification, is better if the entire
paragraph is dropped.

However, as noted above, the document seems to confuse authentication
and authorization.  It should separate these constructs and deal with
them in some detail.

   2.1 Positive Problem Statement
   ...
   When a message is transferred via SMTP between two UNRELATED parties,
   does the SMTP client host have permission to send mail on behalf of
   the mailbox that allegedly caused the most recent introduction of the
   message into the mail delivery system?

The phrasing and scope of the problem statement question is excellent.

It describes a concern for author/sender authorization of the MTA
path that a message follows.

   2.2 Negative Problem Statement
   This section describes alternate questions, which this document makes
   no attempt to solve.

This section is rather different from what it purports to be.  In
reality, it attempts to comment on related techniques.

Given that this is a specification document, no such comparison is
really needed. Worse, I know that the CSV description is flawed, and
suspect that others are.

The section is not needed for the coherence or correctness of the
specification, so I suggest removing it.

   Given an email message, and given an IP address from which it has
   been (or will be) received, is the SMTP client at that host address
   authorized to send that email message?

I suggest:

   Given an email message, and given the IP address of the sending
   SMTP client, from which it has been (or will be) received, is the
   SMTP client at that host address authorized by the Purported
   Responsible Address to transmit that email message.

Because of the store-and-forward nature of email, there are lots of
senders and receivers for a message, so it is best to be quite
explicit that this is the latest-hop SMTP client that is being
evaluated by the latest-hop receiving SMTP server, and that
authorization comes from the RS. (The caps show that it is a formal
term.)

   (3)  Find the E-mail Policy Document for the purported responsible
       domain.  Section 5.1 below describes the semantics of an E-mail
       Policy Document.  Section 5.2 below describes how to find the
       document for a domain.  The E-mail Policy Document contains a
       description of a "client authorization function". This function

<<<< computational cost/complexity, dos exposure, etc >>>

   4. Determining the Purported Responsible Address

I am skipping over direct evaluation of the contents of this section
in favor of a 'strategic' suggestion for it.

I believe this section is a pure clarification to RFC2821/RFC2822 and
stands independent of the current specification. I suggest breaking it
out into a separate document and, especially, circulating it through
the 2821/2822 community (ietf-smtp and ietf-822 mailing lists).

Let me state this differently: marid-core does not innovate the
construct of responsible sender. Its purpose is to use that construct
in some specific ways. However you have noticed that existing Internet
mail specifications leaves the construct fuzzy and you have
contributed text that seeks to clarify it. All of this is goodness.

What is not so good is to bury this clarification of a basic email
construct in an MTA authorization specification.

(I know we went over this in my comments on the Submitter document;
but I'm trying to be complete, here. Plus I'm phrasing the basis for
the suggestion a bit differently.)

   5. E-mail Policy Document

   An E-mail Policy Document is modeled by an XML infoset that contains,
   among other things, a definition of the function ...

I have always understood that a "function" has operators.  In the
definition of the infoset, I do not see any operators.

So isn't this is really something akin to a macro-based access control
list?

(By the way, the IESG is going to ask about the computational
complexity and load of this mechanism, and of the exposure to DOS
attacks. I've just had them challenge a rather more modest spec on
these grounds.)

   7.2 TCP Attacks

   This mechanism is designed to be used in conjunction with SMTP over
   TCP.  A sufficiently resourceful attacker might be able to send TCP
   packets with forged from-addresses, and thus execute an entire SMTP

TCP has segments, not packets, and it has no "from-addresses", so I am
not sure what sort of TCP Attack is being described here.  My guess is
you mean "SMTP Attack" or, rather "Email Sender Forgery Attack" but
the rest of the section appears to be about a replay attack based on
predictable SMTP and TCP content from the server.

   blind û the attack will be unable hear any of the server's side of

note the problem character after 'blind'.

   Attacks of this sort can be ameliorated if IP gateways refuse to
   forward packets when the source address is clearly bogus.

what "IP Gateway" are you referring to and what do you mean by
gateway, here? How is the gateway to know that the source address is
bogus?

   7.3 Forged Resent-From Attacks
   ...
   In order to avoid this attack, MUAs will need to start displaying at
   least the header that was verified.

This section highlights that this specification is about
accountability and not accreditation.

The suggestion about displaying the Resent-From header presumes that
this is a useful technique for detecting forgery. It presumes some
human factors that do not match empirical evidence.

   9.2 E-mail Forwarders

   A program that forwards received mail to other addresses MUST add an
   appropriate header that contains an email address that it is
   authorized to use.  Such programs SHOULD use the Resent-From header
   for this purpose.

Resent-From is a pretty interesting choice to suggest.  At the least,
it is worth noting that this is a change from existing mailing list
behavior, since they usually set Sender.  I'm not saying that
Resent-From is a bad choice, but merely that the fact of changing
mailer behavior is probably worth noting.

I'm also not sure whether I think that Resent-Sender is better than
Resent-From.  Mumble.

Oh... You distinguish email forwarders from mailing list systems. I do
not understand this. what, then, is an email forwarder?

d/
----- 
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>

---

From: Tony Finch <[email-masked]>
Date: Sat, 10 Jul 2004 12:19:55 +0100

On Sat, 10 Jul 2004, Dave Crocker wrote:
>
> By the way, the IESG is going to ask about the computational
> these grounds.

I reviewed the SPF spec from this point of view a couple of months ago,
and I concluded that it was only just short of being Turing-complete
(ignoring the implementation limits that restrict the size of the
computation). A slight enhancement to the macro language would give it
full computational ability.

http://archives.listbox.com/[email-masked]/200405/0075.html
http://archives.listbox.com/[email-masked]/200405/0080.html

However from the point of view of protocol design Turing completeness
isn't such an important property. Based on some quick hand-waving, I
believe it is possible to create SPF records that require an execution
time that's exponential in the size of the record, with storage
requirements that are linear in the record size. I can't think of a
construction that would require enormous storage.

Implementation limits are ABSOLUTELY REQUIRED to avoid problems.

I have not reviewed the current specification with this in mind.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: VARIABLE 3 OR 4. OCCASIONAL RAIN OR DRIZZLE.
MODERATE OR GOOD &NBSP;.