Re: [ietf-dkim] What's a replay?

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  
message replays.
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  
accountable domains.
> 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  
> keys?
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.
-Doug


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