Re: [ietf-dkim] Re: DKIM and mailing lists
2006-01-20 12:25:26
On Jan 20, 2006, at 10:18 AM, John R Levine wrote:
Hey, wait a minute -- isn't that what lists already do?
The discussion was whether the DKIM signature itself can serve as
a basis for acceptance. In other words, can a DKIM signature
safely accrue a reputation?
If the answer isn't yes, I think we're wasting our time.
From the recognition stand point, DKIM still offers value. Without
addressing the replay abuse issue, DKIM will not offer value with
respect to acceptance.
A best practice where all DKIM recipients immediately overlay
incoming signature with a signature assigned the role of MDA by
the MDA that would not be accepted by any other MDA would ensure
messages available for replay could be contained.
Even assuming that one thinks replay is a problem that DKIM needs
to address, which I don't, it's hard to imagine a rule like this
being implemented widely enough to be a problem for bad guys.
Any large domain today has a steady background of abuse taking
advantage of the domain's size. Other providers are reluctant to
block messages from domains that represent millions of users, where
the abuse is also often limited by rate restrictions. When DKIM
offers any acceptance value, this background abuse can and will be
amplified by a replay strategy. If the large domain can not control
the background abuse, will they bother to do more to control a replay
problem?
Defending the reputation of the signature creates a requirement that
the senders find a way to control the replay abuse issue. Several
have suggested that this problem should be swept under the reputation
services carpet and not be discussed. : (
There are tens of thousands of compromised systems sending out rate
limited abuse within these large domains. This abuse tends to be a
mile wide and an inch deep, but represents in aggregate a substantial
portion. Disseminating domain/signature fingerprints for all of
these potentially abusively replayed messages would unfortunately
represent a substantial amount of data. The bad actors can
immediately amplify their abuse by many orders of magnitude. The
response needed to abate this activity will be encumbered by being a
centralized aggregate of _all_ the replay abuse. In other words, the
bad actor will almost always win this race.
In the dkim-options draft, there were some solutions suggested to
mitigate some of the overhead and to decentralize the revocation by
having each sender publish their own abuse lists. The SSP user level
policy concept could be used to block access. These will need short
TTLs, and be queried frequently. A broad distribution of user
records ensures this resource requires inordinately large caches and
high overhead. There is the alternative of the revocation of the O-
ID which does not return a record in most cases. Either way, this
will require that the sender expend administrative resources in an
attempt to curtail a replay abuse problem. Oh bother.
Initially, DKIM will offer value with respect to recognition and
improved filtering of phishing attempts which does not require the
SSP policy to be effective. Over time, DKIM may offer valuable with
respect to acceptance, but this will depend upon how well the replay
abuse can be handled. Establishing from the start a practice that
ensures that a replay-able signature is never seen by a user would
greatly assist in limiting the exposure. If the recipient has not
implemented DKIM, it may not make much sense from an acceptance
standpoint to sign messages destine to these domains. After all,
signing takes some resources, so why use it when it may create a
problem. Perhaps initially, there could be a list created called
DKIM-Adopters. Unless the domain acknowledges that they protect
incoming signatures and utilize DKIM for acceptance, they would not
be added to this list. Any replay abuse that occurs from messages
sent to one of these domains could be grounds for removal. Over
time, the list may invert to represent only the abusers, depending
which list represents the smaller population of names.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Re: DKIM and mailing lists, (continued)
- Re: [ietf-dkim] Re: DKIM and mailing lists, Aumont - Comite Reseaux des Universites
- Re: [ietf-dkim] Re: DKIM and mailing lists, Jim Fenton
- Re: [ietf-dkim] Re: DKIM and mailing lists, Douglas Otis
- Re: [ietf-dkim] Re: DKIM and mailing lists, Eliot Lear
- Re: [ietf-dkim] Re: DKIM and mailing lists, Douglas Otis
- Re: [ietf-dkim] Re: DKIM and mailing lists, Eliot Lear
- Re: [ietf-dkim] Re: DKIM and mailing lists, Mark Delany
- Re: [ietf-dkim] Re: DKIM and mailing lists, John Levine
- Re: [ietf-dkim] Re: DKIM and mailing lists, Douglas Otis
- Re: [ietf-dkim] Re: DKIM and mailing lists, John R Levine
- Re: [ietf-dkim] Re: DKIM and mailing lists,
Douglas Otis <=
- Re: [ietf-dkim] Re: DKIM and mailing lists, Douglas Otis
- Message not available
- Re: [ietf-dkim] Re: DKIM and mailing lists, Mark Delany
- RE: [ietf-dkim] DKIM and mailing lists, Bill.Oxley
- Re: [ietf-dkim] DKIM and mailing lists, John Levine
- Re: [ietf-dkim] DKIM and mailing lists, Douglas Otis
Re: [ietf-dkim] DKIM and mailing lists, Aumont - Comite Reseaux des Universites
|
|
|