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

From: "Jim Lyon" <[email-masked]>
Date: Thu, 26 Aug 2004 15:56:35 -0700

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.

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.

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.

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.

-- Jim Lyon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Aug 2004 17:06:56 -0700

> This authorization can only be bestowed by the domain that the mail

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.

> 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 of individual messages.

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

> pursue the first world-view; the fact that it doesn't do the second is

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. : (

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 26 Aug 2004 20:09:09 -0700

Jim,

I think your note does an excellent job of distinguishing basic points
and of doing basic comparison between one message-based scheme and a
class of channel based schemes.

(Caveat: As this note proceeds and I make comments that seem either
critical or competitive, I must assure you that the above paragraph is
quite serious. Your note divides things up in a way that makes it
possible to have meaningful, substantial and detailed exploration of
benefits and differences. This is goodness.)

By way of making things more concrete we can turn the channel-based
analysis into a specific reference.  This will remove the use of 'might'
from the discussion.

Further, the per-message, versus per-MTA view of authorization is a
fundamental distinction.  I am hard-pressed to view either as being
stronger or weaker.  Each appears to have its own role.

However that does leave me unclear about what you meant in your earlier
message that HELO-based is "a whole lot weaker form of authentication."

Thoughts about the appropriate role of each type of validation:

     Channel-based tells us about the aggregate message-sending behavior
     of a specific MTA.  In a world of compromised personal computers,
     this sort of aggregate assessment can be very helpful for
     identifying "pipes" that are more or less dangerous.

     Message-based tells us about a particular author. This is clearly
     useful against phishing. To be useful against spam, the reputation
     of each author must be assessed.

     Note that per-message analysis does not permit the sort of
     aggregate analysis that lets one determine that an entire ISP's
     pool of systems is problematic.

JL> Sender-ID:

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

But there is another identity, namely the identify of the Sender.

And there is an inherent difficulty in using IP addresses, because they
are so ephemeral, at least due to their being tied to topology.

(I've noted before that it is very strange to see the IP and routing
world moving away from using IP Addresses as identities, just as some of
the email world is trying to move towards it.)

JL> Authentication:  There is no authentication other than that implicit in
JL> the TCP/IP stack.

Actually that appears to be quite a reasonable form of 'transactional'
authentication, sufficient to the purpose of transit-time services like
email. (It is not just that the IP Address is in the IP Source field,
but that the SMTP session has a sequence of exchanges with that
address.)

On the other hand, I think no one would consider that authentication to
be sufficient for financial transactions or anything else of major
import.

JL> Authorization: ...This authorization can only be bestowed by the
JL> domain that the mail claims to come from.

Right, the author authorizes the MTA.  In particular, the author needs
to register every MTA that might be evaluated on the path to the
recipient.

JL> EHLO-based schemes:

I will, of course, suggest switching this section to refer to CSV, so
that the use of 'might' goes away:

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

yup.

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

CSV does a forward DNS query and uses the A record to validate the name
that is used for this IP Address. In terms of formal technical security
strength, I think this is entirely on a par (neither better nor worse)
than the IP-based approach that sender-id uses.

There is a debate one should have about the potential benefits of using
a domain name as the identifier, rather than using an IP Address.  The
CSV spec explores this and I've hinted at it, in the above comments
about using an IP Address.  The summary is that using the domain name
can have vastly better administrative and scaling properties.

JL> Authorization:  [CSV uses] a scheme to determine whether the sending MTA
JL> is authorized by its domain owner to be an SMTP client.  There is no
JL> authorization of individual messages.

Given that it's channel-based, you are indeed correct.  And by the way,
note the potential scaling benefits.  You do one validation per session,
rather than one per message.  In some scenarios, that is a huge savings.

Even better, note the difference in registering the relatively small
number of sending MTA domain names, versus the very large number of
message authors.

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

And I certainly agree, except for the fact that sender-id does, in fact,
try to valid both the message (sender) and the channel (MTA).

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>