[ietf-dkim] What's a replay?
dotis at mail-abuse.org
Tue Aug 9 18:18:28 PDT 2005
On Aug 9, 2005, at 4:38 PM, Eric Allman wrote:
> You have said that you are opposed to per-user keys because of the
> potential damage to DNS (or at least that's my understanding). I
> think this is a legitimate concern even if it doesn't actually
> damage DNS, since the large number of queries for different values
> will trash caches on DNS servers.
The concern is rather simple. DKIM as it currently stands, only
offers per-user-keys as a possible solution to control replay abuse.
This would also mean these many records would need short TTLs in
order to be effective within a relatively short time period. It is
also possible, as a defensive strategy taken when caching problems
occur, the DKIM related keys would be excluded from the DNS cache by
modified DNS resolvers.
When there are a few DKIM keys published per domain, the impact this
should have on both DNS traffic and cache should be within a realm
that can be accommodated as DKIM becomes deployed. When the number
of keys is instead proportional to the number of users, rather than
the number of domains, this would represent an increase in DNS
burdens that would be many times greater. Perhaps this could
represent 2 to 6 orders of magnitude increase. I tried to be careful
and avoid dire terms, while also requesting this issue be reviewed
before including this user-key feature within DKIM, specifically
'g=', while also advocating an alternative solution to defend against
It seems if the goal is to provide user-keys, then S/MIME would be a
better starting point. Although I also think the advantage of easy
deployment is also lost as a result. In my view there is adequate
merit in protecting the domain's reputation without over-reaching and
attempting to defend the local-part with DKIM. I understand the
justifications used for including the local-part in "some" keys, but
this seemingly has lead to short-comings where far greater user-key
deployment may be required. It would also seems impossible to
dissuade user-key abuse by other applications as well.
When the goal is the protection of the domain's reputation, then
offering a policy that permits a 'third-party' sub-domain signature
constraint would actually be better than user-keys. Obviously
constraining just the local-part does not prevent abusive messages.
I like the term accountable domain, as should there be any abuse, the
authorization for the account should be immediately withdrawn. Any
local-part constraint should remain a function of the domain's
handling of specific accounts and completely outside DKIM. The local-
part should not become a function of even more complex constraints
within DKIM in my view. This should be about reputation and
> But you are also pushing revocation ids. For those to be useful
> they have to be fine granularity (if they have the resolution of a
> selector then they don't have much point), perhaps even finer than
> per-user keys (since they could be per-message). They also need to
> have short TTLs, for obvious reasons.
The ideal granularity of the revocation-identifiers would be at the
account used to gain access. When there are no accounts, then
perhaps the revocation-identifiers could be sequentially assigned
during log-ins at access kiosks, for example. There is a means to
mitigate the lookup of the revocation-identifier within the bad-list,
when seeing the HELO is within the domain of the signature. The
authentication of the HELO and a subsequent name based reputation
check could provide DoS protection and enhance the benefits of name
versus IP address reputation. This enhancement would reduce the
level of collateral damage by a reputation services. This HELO
authentication also provides assertions, and may eliminate subsequent
lookups of the domain's reputation. These are a few significant
justifications for making this single albeit small query.
Assuming that the HELO query is not made, then for each signed
message, a lookup for an 'A' record at the revocation-identifier
above the accountable domain would be made. Only when the revocation-
identifier's is considered bad by the domain administrator, would
there be a record returned. This hopefully rare event where an 'A'
record is returned could have a long duration. The negative result
would depend upon the implementation, but the duration of a negative
result would be relatively brief.
So there are a few things to consider. There is a way to mitigate
this lookup. The resources consumed within the cache would be
minimal and brief. The amount of network resources would also be
minimal, and comparable to existing back-hole listing techniques that
occur at roughly the same rate. User-keys on the other hand may
represent the exchange of a huge amounts of information, should these
records become deployed as required by the current DKIM design.
> It seems like the obvious place to store revocation information is
> in DNS (so that you don't start having to add additional ports,
> which is a problem from a firewall perspective). If you don't
> store the revocation ids in DNS then you have substantially raised
> the bar for using DKIM. But if you do store them in DNS, aren't
> you actually trashing DNS in exactly the same way as with per-user
Short lived negative results of 'A' records lookups is significantly
more lightweight than user-keys. This load is also distributed among
the sending domains rather than from a centralized service. This is
not attempting to use wildcards to ease the publication of user-keys.
More information about the ietf-dkim