ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Replay isn't the problem, spam is the problem

2005-08-12 00:58:47
On Thu, 2005-08-11 at 15:50 -0700, Michael Thomas wrote:
Amir Herzberg wrote:
Replay protection allows automated reputation management  [...]

The last I checked, reputation wasn't in scope of the current
charter. There didn't seem to be much controversy about that.
I'd suggest that unless there is some threat about so-called
replays that affects with the current scope of work, that
we defer these discussions until reputation is in scope.

Mike,

Discussions regarding reputation or accreditation _services_ would be at
best premature, and likely better done elsewhere.  With respect to DKIM,
these services should be out of scope.  I also think that until goals
are clearly defined, domain policy assertions fall within that category
as well.  It does not matter _how_ reputation is conveyed to the
recipient.  Nor should this conveyance concern DKIM.  Consider these
reputation services a black-box. 

DKIM removes normal schemes used to limit damage created by abusive
accounts that may inadvertently be hosted by a domain.  With this loss
of control, DKIM actually creates additional problems that must be
solved.  Methods of rate limiting, review of logs, and disabling access
will not provide a positive means to control the damage created by
abusive message relay.  The current DKIM architecture does not provide a
means to avert this damage, other than publishing a separate keys for
each account.  There is also the issue of needing DoS protection, in
addition to message replay abuse issue.  Yes, another problem created by
any signature scheme. 

You want domains to endure the harm created by abusive message replays
with a stiff upper lip, because dealing with this issue is out of scope?
Well okay then, what is left?  Without abusive replay protection,
message acceptance can not safely be based upon the domain verified by
DKIM.  Exactly what relief does DKIM provide then?  Perhaps in security
parlance, what threat is prevented?  Without protecting the domain name,
the domain name will have little value as a basis for accepting
messages, and is in actually greater peril.

This lack of protection for the domain greatly multiplies the complexity
of the problem facing a recipient attempting to make a very simple
decision- Do I trust the accountable domain?  Instead this seems to
change the decision to be- Do I trust the message content?

DKIM only checks one element, the signing domain.  Unless every account
is provided a key that also constrains the local-part, DKIM can not
extend assurances beyond the verification of the domain.  At least when
there is a local-part in the key, this suggests the domain can revoke
the key's use.  Without user-keys, perhaps DKIM could attempt to shift
trust to be based upon the virtually unique signature within the
message, as Jim once suggested.  Imagine that the black-box is bigger
and tracks all signatures rather than just domain names for abuse.     

What is lost by using this big black-box?  If the check could be just
for the domain name, then authenticating the HELO would also provide DoS
protections using a little black-box, and this could extend to include
the domain verified by DKIM.  But instead two black-boxes are needed,
big and little.  What problem is in the way of using the DKIM verified
domain name and only needing the little black-box?  Replay abuse.  Why
will domains consider publishing giga-bytes of user-keys for their
domain?  Replay abuse.

Even giving each user their own key assumes a great deal about the
security associated with key handling and how individuals are
authenticated by the system.  Even when the recipient does their own
signing, the chances of such a mechanism being compromised are rather
high, and will involve many years of effort to get this somewhat secure.

Does DKIM really stop spoofing?  When any number of extraneous
conditions unrelated to DKIM are met, then perhaps.  But the recipient
would still be clueless whether this is actually the case.  The
recipient will see countless examples where believing the local-part
with DKIM could lead them astray.  

Does DKIM really stop phishing?  The phishers may actually take
advantage of DKIM to obtain greater credibility.  There are many holes
in DKIM, when attempting to shore up what the recipient sees.  Just like
user-keys, this will likely become another major effort.

One way to keep this effort simple would be to only ensure the domain
that was authenticated is exposed to a black-box or the recipient.  Stop
there.  With just that accomplished, is DKIM a complete solution?
Almost. The silly little problem remains.  Replay abuse.

What quality of protection would any black-box provide when every
instance of abusive message replay must be ignored?  Not good.  Roll out
the big black-box.  Without everyone having access to this big black-
box, the domain would be powerless to protect these unknown recipients
from possible abuse that bears their name.

Perhaps domains could offer their own free service aimed at only
removing authorization from abusive accounts, without needing to issue
user-keys to every account.  Gosh, this has nothing to do with the
black-box, but would allow domains to protect these unknown recipients
as well as their name in the bargain.  Replay abuse, key abuse solved.  

-Doug


   

   

_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim