On Wed, 2004-09-15 at 15:37, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
I thought we were discussing security terms, not Latin.
We are discussing the difference between send control lists and
authentication.
Side-lines into Latin, and what words meant 2000 years ago aren't
helpful. If they were, we wouldn't be using the letter "j", and we
would be pronouncing "v" as "w".
But through this period, the word has not changed meaning.
To refresh this point:
http://www.imc.org/ietf-mxcomp/mail-archive/msg04648.html
My point then, as now is:
- Entities who have information should use it to make decisions.
The goal of this effort should also include providing essential
information to enable locating and correcting problems. This would be
together with the other goal of detecting spoofed addresses.
- Entities who do not have information cannot use it to make decisions.
Ignorance is bliss? : )
You are advocating Sender-ID or SPF identities are authenticated. I
still claim this is a misuse of the term authenticate as this presumes
the integrity of the mail channel and the nature of the list.
It presumes that the entities publishing those records have read the
specification of the protocol they're implementing, and understand
it's costs and benefits. The meaning of those records is as defined
in the specifications, nothing more, or less.
I see a conflict even within the specification. Jim Lyon has already
indicated any domain publishing an "open" record, requesting forwarded
mail receive a "Pass" assessment, will receive the bad reputation they
deserve. The specification does not warn of this problem. There is
another problem with any "open" record, even those that only request a
"Neutral" assessment. SPF and Sender-ID use DNS records for the double
purpose of "authenticating" the MTA in conjunction with listing MTAs
authorized to send messages for a specific mailbox domain. This
provides the MTA with the extremely weak identity of the mailbox domain.
When the record is "open" for SPF or Sender-ID, this invites spoofing of
the mailbox domain to obtain "authentication." This invited spoofing is
very much counter to the goal of stopping the spoofing!
By first performing CSV to authenticate and authorize the MTA, and then
obtaining an authorization list of names referenced by the mailbox
domain, this will specifically prevent spoofing. This two step approach
can not be exploited for the purpose of "authentication" to usurp the
reputation of the domain. The weak "authentication" of Sender-ID or SPF
may be accomplished by simply asserting the mailbox domain in some
cases.
marid-mpr was to illustrate solutions for those interested in:
a) Stopping spoofing
b) Not breaking mail
c) Providing fairly applied reputations
d) Locating abusive MTAs
e) Using lightweight and deterministic overhead
f) Retaining network integrity
g) Retaining DNS integrity
h) Optional assertions on RFC2822 From that are not superseded
I noted the hazard making this assumption would cause with respect
to harming reputations of those that, through no action on their
part, receive negative assertions.
Again, your focus is on reputations and negative assertions. Mine
is not.
My focus encompasses your concerns. If you review the marid-mpr draft
and consider how it can work, you will find it actually provides better
protections than SPF or Sender-ID, but without the overhead and the IPR
problems.
http://www.imc.org/ietf-mxcomp/mail-archive/msg04818.html
Your response to that message didn't acknowledge that my goals are
different from yours. While I understand very well your concerns
about negative reputations, I do not see reputations as the primary
goal of SPF, Sender-ID, or the MARID WG. Instead, what's important is
the ability of a domain to publish a list of authentic outgoing MTA's.
The goal of authorizing the MTA is defined in the charter and made
somewhat explicit in the WG acronym. By first identifying the MTA,
independent of any authorization, offers a few important benefits-
a) Stronger identity for asserting reputations
b) Deterministic structure based upon names for authorization
c) Location of a problematic MTA
d) Prevention of record exploit and improved spoof prevention
e) Thwarting phishing when making the validated MTA identity visible
f) Retained mail functionality with safe "open" lists
g) A phase-in with open lists only "coloring" mail, not rejecting it
Reputation systems are secondary to the primary goal, and are
piggy-backed on top of it. I don't see a need to discuss MARID-based
reputation systems until such time as we have a clear specification of
not only an MTA authentication system using DNS, but also the costs
and benefits of using such a system.
There should be some consideration given this, as you have indicated
your own expectation the results of this scheme will be used for
establishing reputations. As Sender-ID and SPF provide such incredibly
weak identities, these identities will actually become more vulnerable
to harm caused by spoofing, but now from reputation services. This will
happen due to an understanding SPF or Sender-ID strengthened these
identities. As this is going from zero strength, the slight increase
and the surrounding hype make inappropriate reliance on these identities
far more likely.
If that MTA authentication system is correct and useful, then
reputation systems can be built on top of it. If the MTA
authentication system is not correct or useful, then any reputation
systems which depend on it will be likewise useless.
There are fundamental flaws with the SPF or Sender-ID scheme. A list
may be "open" but such an open list is not made apparent to the
receiving MTA in all cases. A sending MTA may be shared, but such
sharing is not apparent to the receiving MTA. The Sending MTA may not
have made SPF or Sender-ID record checks upon receipt of the message
being sent, but this also is not apparent to the receiving MTA. As a
result, there is validation promotion moving through these shared MTA
clients. Essentially any domain accepted by the client MTA, may spoof
any other domain that also shares the client MTA and is using an "open"
list or where the sending MTA did not make the needed checks.
Even with full compliance to the specification, spoofing remains
possible. This is creating a new danger where, had it been understood
not to trust the mailbox domain identity, there would be less risk. The
hype used to promote these schemes suggests such identities can be
trusted. Of course there are many ways to inject mail into the mail
channel that may bypass the needed checks, but where such an event can
not be detected using SPF or Sender-ID. Both Sender-ID and SPF are
trusting the integrity of both the sending and receiving administrative
realms, but where there is no means to verify such assumption.
Sender-ID and SPF are ideal mechanisms for the confidence artist.
There have been some that suggest any shared MTA should become a thing
of the past as a result of these flaws of Sender-ID or SPF. These
shared MTA strategies, sometimes forced by blocking ports or by way of
transparent interception, are effective at curtailing abuse originating
within a providers networks and allows the provider to protect the use
of their IP address space. This largely requires the examination of the
SMTP logs and finding too many nonexistent recipient errors. This
shared MTA can also direct abuse@ messages to assist in the effort to
curtail abuse as well.
I am not suggesting curtailing spoofing not be done. I am simply
advocating a better, safer, cleaner approach. And yes, it also makes
reputations safer as well.
-Doug