ietf-dkim
[Top] [All Lists]

Re: The Value of Reputation (was Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim))

2006-01-01 16:02:08
Folks,

Selamat tahun baru.


Unless I have missed something quite basic, the proposed DKIM charter and the
draft DKIM specifications do not include doing work on reputation services.
That many of us expect (and even intend) that one of DKIM's uses be in
reputation services does not mean that we must discuss that topic at any length,
in this venue, at this time.  In fact, reputation services are intentionally
factored out of the DKIM work, except for attending to exactly one question:

     DKIM provides a means of validating an identity that is associated with
message transit.  Do we believe that that validated identity will be helpful for
some variety of email [quality] mechanisms, such as reputation services?  The
answer to this is yes, since there is a long-standing value in having an
validated, accountable identity associated with a document.

Other discussion of reputation services strikes me as extremely important, but
entirely outside the scope of a DKIM working group.

I therefore will ask why folks feel it must be discussed in this venue, at this
time, rather than -- for example -- seeking to make forward progress on the DKIM
technical work?


   I've noticed a lot of what I call "lip service" about the critical
role of reputation. To say this differently, many folks seem to think
you can choose a "reputation system" almost at random, and it's sure
to improve your signal/noise ratio, "unless you've chosen the wrong one".
(which, I suppose, is a tautology...)

"Many folk seem to think" is sufficiently broad and tenuous as to make its
validity and utility questionable.  For example, *I* have not seen any
significant basis for this concern among the folks who are trying to do the
actual DKIM technical work and deploy it in real-world operational environments.

As such, it is worth justifying this concern, before spending time addressing 
it.


   But, in my view, we have no basis to choose the "right" one unless
we have a good understanding of what it measures and a workable idea
of how to "end run" when it falsely rejects good messages.

This sounds suspiciously like "We must understand the entire problem space and
the entire solution space, before we can permit ourselves to make choices about
pieces."


I see the cycle as going like this:  We need at least one
standardized, moderately-useful system for weakly authenticating
the sources of messages.  Once we have that, we have the minimal
data that a reputation system will require to be able to start
doing something at least mildly useful.

   A lot depends on what we mean by "weakly authenticating".

Probably correct.  So it is quite useful that we have access to a concrete
specification that embodies the meaning that applies here.

We do not have to guess and we do not have to compare it to other uses of the 
term.


   As a practical matter, _many_ folks will prefer sorting through
100 spams to losing one good email. I see darn little "market" for
anything which can't get it 99% right.

"Many folks" are free to use whatever mechanisms they find helpful.  The point
behind DKIM is that "many folks" believe it to be worth pursuing.

As for judging exactly what the limits of market acceptability are, there are
two problems with attempting to conduct such a discussion here:

   a) standards bodies, including the IETF, have very poor track-records
predicting market acceptability, particularly when the discussion goes beyond
merely assessing the competence of the technology.

   b) there is a substantial constituency of experienced and responsible
development and operations folk who find the DKIM mechanism appealing enough to
be worth pursuing.


  - - - - -


Global reputation vetting is a hard problem.  To a considerable
extent, that makes a strong argument for local reputation
assessment, not for identifying those who cannot be
reputation-validated as spammers but for giving preferred
treatment to those who are on some preferred list.  As I
understand it, that is a major motivation of at least several of
those who are pushing DKIM.  So far so good.

I believe that local-vs-global is largely orthogonal to the question of whether
to focus on identifying the good actors, versus focusing on identifying the bad
actors.


The difficulty is that establishment of such a mechanism makes
it very easy for, e.g., an ISP that wants to "protect its
customers from spam" and reduce spam traffic on its backbone to
say "aha, any message that isn't validated/authorized by someone
whom we recognize is obviously hostile and should be silently

It is often easy for people to make simplistic and incorrect choices in how they
use a mechanism. This does not seem like a very strong argument against creating
the mechanism.

The general form of the concern that appears to be getting expressed here is "an
otherwise-reasonable and useful mechanism is easy to misuse, therefore we need
to consider avoiding making it available (or we need to spend a lot of effort
warning people against their silliness and stupidity.)

In this form, of course, the concern does not seem so reasonable.

(Another example of such logic is:  "Pornographic pictures are evil, so we must
not make it easy to attach them to email, so let's not create MIME.")


   But, in practice, we know that those marketplace
mechanisms often don't work terribly well.

Except for the fact that they work far better at choosing standards than any of
the alternatives...


Now using DKIM, or a wide variety of other techniques, this way,
would clearly be abuse of the intent of the methods.  But one of
the things we all should have learned by now is that a
technology that can be abused almost certainly will be abused.

We've learned much more than that.  We have learned that there is an infinite
range of abuses possible (and usually likely.)  We have learned that we are not
very good at protecting people against their own silliness and stupidity.  We
have learned that we are not very good at predicting which abuses people will
prefer.  And so on...

Therefore we SHOULD have learned that our obligation is to write clear
specifications for understandable mechanisms that do useful things.

*That* focus, rather than one that worriess about myriad psychosocial
hypotheticals, has proved far more constructive for IETF work.


It seems to me that, were DKIM to succeed, we would run a
significant risk of seeing the Internet fragmented into
DKIM-approval camps (with the non-DKIM-users left out of all of
them).

1. You might be right, but I can't tell, because I do not see a) the logic
sequence that starts with the fear you express and leads clearly to the
conclusion, and b) the basis for certitude that the fragmentation will occur.

2. How is this different from the "fragmentation" that separates those with MIME
support from those without, or the "fragmentation" that separates those with TCP
selective acknowledgment support, from those without, or... any other
fragmentation that distinguishes among supporters of enhancements from those not
(yet) supporting it?


Again, this is not an argument against chartering a WG.  It
might be an argument for insisting that such a WG explain, as
part of proposing something for standardization, how obvious
abuses of it are to be avoided or repelled.

My "obvious" is probably not your "obvious".  This will lead to lots of extra
work, debating what is "obvious".

This seems to suggest a policy requirement for all IETF work, that it anticipate
and document "obvious" abuses and specify the means of avoiding them.

This feels more like a bureaucratic barrier to productive work, than a useful
adjunct to the technical specifications work that the IETF tries to perform.

d/


--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>




--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org