Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
On 12/17/10 8:03 AM, John Leslie wrote:
Obviously, it is possible to authenticate differently, and Doug
has wrapped his mind around several different mechanisms over the
last five years. None of them, IMHO, work very well in the time
domain (delivering results that may be outdated, and struggling to
mitigate replay problems). But they are certainly better than
relying on IP addresses alone.
DKIM has a limited basis for accruing reputations,
One can accrue reputation for a DKIM signer, just not a reputation
for the particular SMTP client sending you the message.
(Also, the reputation will necessarily be compromised by any
intervening sending SMTP client and/or any spammer that manages a
replay. Exactly what the reputation would mean is a bit obscure.)
since this protocol neglects confirmation of destinations, which
would not be a problem with CSV.
DKIM, of course, means to authenticate the _message_ -- which is
a useful thing, but not particularly correlated with reputation.
As a result, DKIM domains can not be applied against undesired
messages on the basis of destination alone. DKIM however inhibits
false-positives with anti-phishing filtering.
The principle in CSV was to have the sending SMTP client declare
its identity in HELO or EHLO, and have the receiving SMTP server
authenticate at SMTP time that the domain authorized that client
to send according to its policies. (Of course, those policies do
not necessarily match the policies of domains named in MAIL FROM or
any similar domains which will be visible to recipients.)
Now that v6 deployment methods have become apparent, using IP
addresses to confirm EHLOs is likely to become increasingly error
prone.
True... but not so much as to prevent me from trying it under v6.
SPF will equally fail, even with its many transactions involved.
I quite disagree: SPF will fail far more spectacularly. It will be
hard to come up with SPF RRs that do something useful and don't assist
DoS attacks.
In addition, when SPF is used in conjunction with SMTP transactions,
this will also represent a DoS concern, especially with DNSsec.
I know nobody believes you -- under v4 this problem hasn't really
surfaced. I'm hoping SPF doesn't see enough v6 deployment for this to
become an issue.
At the last MAAWG meeting, consensus was reached with a statement that
SPF can not be used to abate spam.
SPF, BTW, could have been a useful tool if MARID had lasted long
enough to write up what particular SPF atoms _mean_ instead of just
specifying algirithms to evaluate them. Folks _have_ tried to use
SPF RRs in "non-standard" ways to glean the information they want,
but it really can't work very well.
SPF offers a method to determine which IP address block-lists affect
a domain's delivery, and secondly as a method to qualify feedback
streams.
The first can be done better by other means; the second is an
attempt to overlay a meaning after the fact. Myself, I wouldn't
use it.
Sender-ID was considered unusable and ineffective.
Alas, those folks meant well -- but the design was never fixed to
allow reasonable experimentation. Both SPF and Sender-ID believed
the most important thing was early adoption by senders; and IMHO
neither accomplished that (except for nearly-useless RRs published.)
CSV relied on a weak but timely authentication; we have since
seen alternatives that are stronger but less timely -- the principle
of authenticating the SMTP client talking to you is more important
than the exact balance between strength and timeliness.
Likely some extension of RFC4954 will be needed, where public keys are
used to confirm hashed and signed challenge responses.
That could work, but the key-infrastructure seems problematic. It's
also rather heavyweight and burdens the receiving SMTP server overmuch
IMHO. Something of that ilk would be more useful _after_ weak
authentication of the sending client indicates minimal ground for
trust. (Or, of course, a micro-payment system to cover costs...)
This might use DKIM's public key or whatever resource is created by
the keyassure wg.
I don't believe a "keyassure" WG exists. There is a proposed "kidns"
WG which may be created soon. I've lost track of what the difference
is supposed to be -- for all I know, it may end up created under some
other name entirely...
In any case, the kidns proposal calls for:
- Jun 2011 Protocol for using DNS to associate domain names with keys
for TLS and DTLS to IESG
- Aug 2011 Protocols for using DNS to associate domain names with keys
for IPsec to IESG
We shall see...
There must also be conventions about the name determined.
I'm not sure where those might come from... :^(
In principle, it may be possible to build a business model with
even-weaker authentication by IP-address and unknown timeliness;
but I wouldn't want to be the one trying to build it.
Terabytes of logs processed daily for just v4 is already staggering.
Indeed! Myself, I'd try to avoid that path.
The same approach with v6 simply won't work. SMTP needs simple and
stable handles that don't involve transport addresses. That is not to
say there can't be a transition strategy using existing conventions as
a means to confirm server/mail-domain names.
I still see no reason to abandon the HELO string...
Being able to combine v6 and v4 into common reputation queries with
a destination basis for undesired messaging would tremendously aid
SMTP's transition into v6, while also improving the state of SMTP
in general.
Clearly, spammers and other miscreants will continue to congregate
where the pickings are easy. I doubt they want to be bothered with IPv6.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg