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>