ietf-dkim
[Top] [All Lists]

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