Jim,
While not currently part of the DKIM draft, this threat review
neglects the possible use of an opaque-identifier associated with
accounts providing server access, and the self-listing of revoked
opaque-identifiers described within:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-03.txt
When excluding the described strategies, the following paragraphs
essentially claim cases where there is a lack of threat protection
derived from DKIM deployment:
4.2. Within Claimed Originator's Administrative Unit
When DKIM is combined with an opaque-identifier associated with the
account used to access the server, DKIM would enable highly effective
correlation of abuse sources emerging from within an Administrative
Unit without exposing private information. Inclusion of a tamper-
proof identifier within the message would offer significant value
addressing problems within an Administrative Unit for all affected
parties. This opaque-identifier strategy is made possible with DKIM
deployment.
4.3. Within Recipient's Administrative Unit
When DKIM is combined with an opaque-identifier associated with the
account used to access the server, in conjunction with opportunistic
identification pseudo-certificates, DKIM could be highly effective at
identifying prior correspondents within an Administrative Unit. This
opaque-identifier strategy would be made possible with DKIM deployment.
5.2.3. Reputation Attacks
When DKIM is combined with an opaque-identifier associated with the
account used to access the server, this permits timely and effective
account revocation by publishing an address record following a
namespace convention. Publishing could be delegated and there are
simple strategies for mitigating most revocation checks. Again, this
opaque-identifier strategy would be made possible with DKIM deployment.
6.3. Message replay
Dealing with Reputation Attacks using opaque-identifiers may quickly
abate message replays and would be much faster than key removal, even
if key removal was practical and TTLs were brief. Without user-key
granularity, key removal would be disruptive. When for large
domains, user-keys with short TTLs could represent a significant
resolver burden. Replay is a significant concern from a reputation
standpoint, as normal strategies for preventing abuse are ineffective
against replays.
There is also expectations that "content filtering" (perhaps
signature-fingerprints) may be published by third-parties as a means
to abate a replay problem. That 'content filtering" strategy
increases response times, and creates an expense for the recipient.
Self-listing of revoked opaque-identifiers would be much faster and
would not introduce the added expenses for third-party services. In
addition, checks for the revoked opaque-identifiers could be
mitigated, whereas a third-party service does not offer this
possibility.
----
There is also a safer alternative to that of the SSP approach. This
will be of greater concern when initial deployment is primarily
signatures by third-parties.
6.1. Unsigned Messages
There is an alternative to SSP. SSP mailbox-domain authorization
introduces administrative, protocol, and support requirements, in
addition to enabling exploits. Mailbox-domain authorization exploits
were not covered by this draft.
Opportunistic identification using pseudo-certificate strategies, in
conjunction with binding recommendations, enable better protections
from spoofs of previously signed correspondents. This approach would
not depend upon mailbox-addresses being seen by the recipient, nor
require additional lookups or complex mailbox-domain authorization
administration.
Consideration of these rather simple strategies increases the value
obtained when deploying DKIM. These strategies would offer value for
third-party signing, and not encourage an inordinate number of domain
keys.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org