On Aug 11, 2005, at 7:59 AM, Paul Maddox wrote:
Douglas Otis, wrote:
The concern is rather simple. DKIM as it currently stands, only
offers per-user-keys as a possible solution to control replay abuse.
I'm having trouble seeing the threat with replay.. Can someone help
differentiate these two scenarios:
1. Replay
2. Sending mail from that domain from within the organisation (Eg. An
employee sending thousands of emails through Outlook)
Is the replayer and rogue employee the only problem in both cases?
Any message initially being signed would not be a "message replay".
Rogue accounts or employees could send themselves messages, perhaps
to different accounts, which can then be used to stage "message
replay." The motivations for doing so would be to avoid normal
controls available to the "accountable domain."
If DKIM is supposed to make domain owners responsible for the email
from
that domain, should it not be the domain owner preventing replay/
abuse,
not DKIM?
Yes, indeed. But the current design of DKIM only provides this level
of control when separate keys are used for each account where the
keys also remain held in cache for only a short duration. This will
create inordinate DNS burdens. However, there can be another
solution that imposes much less load on DNS.
------------
Let me define the terms I will be using again.
Message Replay:
Signed messages reintroduced from different servers with different
RCPT TO parameters.
Accountable Domain:
The domain that introduced the signed message and provided the public
key used for verification.
Revocation-Identifier:
An opaque identifier optionally added by the accountable domain and
used to revoke the related account's authorization.
Bad-List:
A set of domain labels at the accountable domain that return 'A'
resource records with the address value 127/8. Only those labels
that correspond to revocation-identifiers which are no longer
authorized, would be published by the domain. Lookups against
authorized revocation-identifiers do not return a record.
--------
While DKIM may provide relatively strong authentication of an
"accountable domain", an inherent feature of a signature permits
"message relay." This "message replay" feature makes it difficult to
hold the domain signing the message actually accountable for ongoing
abuse. Without an ability to apply assertions of accountability,
reputations based upon the "accountable domain" would be meaningless.
Potentially huge amounts of abuse must be excused due to a normal
inability of the "accountable domain" to control "message replay."
This will cause any protective mechanism initially intended to be
based upon the "accountable domain" to instead revert back to the IP
address. DKIM offers the possibility of establishing name based
reputation as a means to prevent collateral damage caused by shared
IP address space, but without a mechanism to deal with "message
replay," this advantage is lost.
Not all "message replay" is bad. Indeed there are times when
"message replay" is desired, such as when there is a list of
recipients, or a recipient is using a forwarding account. One could
argue mailings lists should adopt a practice of using "message
replay" instead of applying new domain signatures to provide those on
the list an assurance of the initial "accountable domain" for the
message.
Holding the "accountable domain" accountable demands a mechanism
where this "accountable domain" can prevent "message replay" when
reports are received with evidence of abuse. For those within a
large domain or where users are not always within a protected
network, it would be prudent to add a mark, a "revocation-
identifier," that indicates which account was used to gain access to
the email system.
I am advocating making this already common practice in such
situations, an optional convention within DKIM. In addition, I am
advocating another convention that allows those domains that adopt
the "revocation-identifier" convention, a means to retract
authorization based upon the "revocation-identifier." The
"accountable domain" would publish "bad-list" records for "revocation-
identifiers" associated with accounts terminated due to reports of
abuse.
This would allow only a few DKIM keys be used for the entire domain.
It would also allow a reasonable duration within the DNS cache where
this would be less likely to create undue burdens upon the DNS
infrastructure.
-----
(Poor attempt as devils advocate.)
Those looking for justification for DKIM without there being a means
to control "message replay" tend to suggest the following:
1) Acceptance will be predicated upon a white-list that is-
a) Comprised of both the local-part and the signing domain
(assumes local-part is normally constrained by domain).
b) Comprised of user-keys.
c) Comprised of the signing domain
(ignores message replay abuse and likely fails).
If DKIM becomes a new way to sign a message with user-keys, then due
to the lack of suitability of user-keys for email within DNS, S/MIME
should be modified instead where key servers are already employed.
After all, user-keys enable message encryption only understood by the
recipient, and this is already accommodated in S/MIME. User-keys
would provide assurances to both the author and recipient of both
identity and privacy.
With market advantages for user-keys, is it safe to start a practice
of publishing user-keys in DNS? Would calling DKIM a domain key with
a "limited" use of user-keys really be just a guise to really provide
everyone user-keys, when there is no other mechanism to control
message replay abuse?
---
DKIM can be a tremendous asset to email, provided it allows a
response to message replay abuse. Key abuse should also be
prohibited by way of design. This means user-keys, at any level,
should not be used. The justification for employing user-keys fall
flat when assessed against a goal of ensuring reputation protection
for the _domain_. The domain would be far better protected with a
practice that constrains less trustworthy keys to sub-domains. By
establishing policies able to constrain "third-party" signing to sub-
domains, the reputation of the domain is far far better protected.
The debate about whether keys should constrain the local-part place
great value in the protection of the local-part, but then completely
dismiss the lack of protection for the domain's reputation.
Constraining the local-part of a message offers only token
protections that a key will not be abused. Third-party signatures
will become common practice, and recipients will be aware which DKIM
verified domain they are actually trusting. DKIM message should make
people keenly aware the entire message's content (everything) is
fully dependent upon the constraints established by the domain.
DKIM's only role is to assure the recipient of just the domain.
Recipients are trusting the authentications required to access the
specific domain. The level authentication varies widely. Should
mobile-users.acme.com gain a bad reputation due to a lapse of
attention (perhaps a Trojan in a salesperson's notebook), then
acme.com's reputation still permits normal commerce. The salesperson
could still use their email address at acme.com's offices. The
mobile key should be used as a third-party sub-domain signature.
The goal for DKIM should be to protect the domain's reputation. DKIM
provides for safe name based reputations and eliminates IP address
space collateral damage and related IP address weaknesses. The
significant remaining threat is message replay abuse.
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim