ietf-mxcomp
[Top] [All Lists]

RE: DEPLOY - IP, HELO & touch count. DOC-BUG too.

2004-08-28 18:32:15

On Fri, 27 Aug 2004 14:52:56 -0700 Jim Lyon wrote:
On Thu, 26 Aug,2004 at 5:07 PM, Douglas Otis wrote:
On Thu, 2004-08-26 at 15:56, Jim Lyon wrote:
On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the
authentication and authorization aspects of SenderID, compared to
schemes involving EHLO.

After much thinking, I realized that our disagreements have to do with
confusions about how the two schemes treat identity, authentication and
authorization.

Sender-ID:

Identity:  The identity of a sending MTA is its IP address.

Authentication:  There is no authentication other than that implicit in
the TCP/IP stack.  Because in practice you can't perform an SMTP
transaction without being able to receive packets destined to the IP
address, this works well. (Yes, I know about TCP/IP spoofing attacks,
but they're impractical for sending bulk e-mail.)

Authorization:  The SenderID test determines whether the sending MTA is
authorized to send mail that claims to come from a particular domain.
This authorization can only be bestowed by the domain that the mail
claims to come from.

The Identity being authorized is the PRA Mailbox Domain by way of
reference to a Mail Channel prescription of IP addresses.  This PRA
Mailbox is the Identity the draft hopes exposed to the user.  The
Mailbox Domain has not been authenticated, only authorized as the Mail
Channel will not safely permit such conclusion.  The domain
administratively accountable for the MTA remains anonymous beyond the IP
address.  There is no identity authenticated through this relationship
unless you wish to claim some significance with the MTA IP address.  If
there is a problem, what identity will the user report?  If there is a
problem, what identity will the MTA/MUA filter or reject?  In each case,
the PRA Mailbox Domain is the identity affected.  The problem is that
this identity has not been authenticated, but the authenticated MTA IP
address is ignored.

No, please try reading it again. The identity being authorized is the
sending MTA's IP address.  The action being authorized is to send a
message on behalf of the PRA.  The organization doing the authorization
is the domain of the PRA.

This is a distinction without much significance.  Restated to suit your
definition would be:

The identity being authorized is (the IP address to send the message on
behalf of) the PRA Mailbox Domain by way of reference to a Mail Channel
prescription of IP addresses.  Of course the Mail Channel prescription
would be administratively controlled by the PRA Mailbox Domain and the PRA
Mailbox Domain resolves the prescribed Mail Channel.

PRA Mailbox Domain -> Mail Channel IP Address prescription -> MTA IP Address

Although the IP address has been authenticated by way of the TCP protocol,
the PRA Mailbox Domain has not been authenticated, as the RFC2822
information is not trustworthy.  The only safe identity resulting when
skiping the steps of authenticating the MTA before resolving authorization
(for sending the message based upon) the Mailbox Domain is the MTA IP
address.  This does not represent much of an improvement with respect to
how reputation can be handled.

Mailbox Domain -> Mail Channel EHLO Name prescription -> Authenticated EHLO

This has the advantage of providing of the EHLO domain being useable with
reputation checks which minimizes efforts needed to track IP addresses of
various entities.  It also has the advantage of allowing the Mail Channel
prescription to be just a simple list of names that do not require
obtaining address lists maintained by other domains to resolve the Mail
Channel. Imagine, one DNS lookup and you're done. : )

EHLO-based schemes:

Identity:  The identity of a sending MTA is its EHLO name.

Authentication:  Various scheme to determine whether the EHLO name that
an SMTP client sent is true.

The goal of CSV is to ensure a consistent and simple scheme
authenticates and verifies MTA authorization.  The identity is the EHLO
domain as the message broker.  This authenticated identity can be held
accountable.   The Sender-ID identity as represented by the PRA Mailbox
Domain has not been authenticated as this requires unverifiable
assumptions made with respect to Mail Channel. Bug.

Authorization:  Depending on the scheme, there might be none.
Otherwise, there might be a scheme to determine whether the sending MTA
is authorized by its domain owner to be an SMTP client.  There is no
authorization of individual messages.

As I said, CSV provides both MTA authentication and authorization.  This
was the goal of the MARID charter. : )

The SenderID series of documents is based on an explicit decision to
pursue the first world-view; the fact that it doesn't do the second is
not a bug.

Not authenticating the identity you wish everyone to hold accountable is
a bug in this logic.  By allowing an "open-ended" record to exist, this
process becomes an exercise in futility, as not even the IP address of
the otherwise anonymous MTA is checked.  Such "open-ended" records leave
open the door for endless spoofing.  Sender-ID's false assumptions of
identity trustworthiness will ensure great potential for harm. : (

(... yet another advertisement for CSV ...)
Ignored as not relevant.

Could I expect a clarification that reputation is not to be based upon the
PRA Domain, but rather the IP address of the MTA?

-Doug


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