ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-threats-00 Overlooking a practical solution while also recommending a highly unfair solution

2006-01-25 03:30:22
On Wed, 2006-01-25 at 08:55 +0100, Eliot Lear wrote:
Douglas Otis wrote:
---[D: Overlooking a practical solution while also recommending a
highly unfair solution.]
,---
|4.1.4.  Chosen Message Replay
|
| ... One approach to this problem is for the
| domain to only sign email for clients that have passed a vetting
| process to provide traceability to the message originator in the
| event of abuse.
'---

Unless there is an expectation that individuals obtain their own
certificates from a trusted authority, individual reputations on a
cost-free email-address would be completely futile and unfair as DKIM
does not necessary verify the valid use of an email-address anyway.

I don't see why you went here.  Use of certificates is certainly one
valid approach but it is not the only one.  Within an enterprise it
should be possible to impose policies in conjunction with simpler
mechanisms such as DKIM to get traceability.

Even assuming that the holder of an email-address can be identified in
some manner, such as the use of individual CA certificates, there is
_no_ way to know which email-address to hold accountable in the case of
a replay attack.  Was it exclusively due to the recipient, or due to a
cooperation between the sender and the recipient.  Indeed, the email-
address to initially suspect would be the recipient.  Looking at the
content _may_ provide a clue whether the sender may have been partially
culpable.  Who knows, perhaps the sender was duped into responding to a
message sent to them.  Perhaps it was an innocent newsletter.

Tracing the problem demands there to be something that can be traced.
When most domains leak enough abuse to create a major problem with
respect to the value of signatures, signatures will not mean much with
respect to reputation.  In the case of replay abuse, without a practice
of overlaying the signature, attempts to hold an email-address culpable
is sure to be futile.  Email-addresses are a dime a billion.  


Once again, one size does NOT fit all.  Especially if the message is
protected.  Remember, deciding whether something is spam generally
does not involve a single input but instead involves many.

A signed message is not, in itself, protected from replay abuse,
regardless of the size of the domain.  The size of the domain does not
matter.  The best moderator will not be able to spot spam that contains
a link to topic related material.  Even by hand, filtering can not be
done reliably enough.  Most domains send _some_ abuse for many reasons.
If that were not true, we would not be talking about DKIM.  

The definition of spam largely depends upon _where_ the message is sent
and much less about what is in the message.  When the message appears to
largely benefit the sender, this would be a clue when there is a
question about whether an individual email was spam.  When there are
millions of such messages sent to those that never desired receipt, even
this message, this would be spam without question.

Unless there is a practice that overlays the signature with results,
there is no one that can be held accountable.  It is not practical to
revoke keys fast enough to make a significant difference in the level of
the abuse.  Any domain would be at risk, some more so than others of
course.  While some domains may remain above the fray, the diminished
value obtained by a signature with respect to acceptance for most
domains, will also likely mean that reputation systems will not offer
much value either.  Even SSP would make little sense for the minimal
benefit.

DKIM has value without being used to base acceptance (sort out spam).
Perhaps adding signatures and not caring about whether they provide any
acceptance or conformance value would be okay.  DKIM could improve upon
filtering of phish attacks, and perhaps that is good enough.

-Doug

 





_______________________________________________
ietf-dkim mailing list
http://dkim.org