On Jul 29, 2005, at 2:32 PM, Michael Thomas wrote:
Douglas Otis wrote:
However, rather than limiting the goal to that of confirming just
the domain, user identities have been included within DKIM.
Despite otherwise sound justifications for including the user
component, this feature should be removed. By including this
feature offering specific user confirmation, this represents a
potential for growth in DNS use that is neither incremental nor
linear.
While I suppose that this is possible, it doesn't seem especially
likely. The
single largest motivation (IMO) for user level granularity is for
outsourced
functions.
This problem is somewhat mitigated by removal of bindings to any
specific From or Sender header. Rather than providing a private key
to an out-sourced vendor equal to that of the parent domain, the
solution could be to offer a special "distributed" or "limited" key.
Let's say such a key has a simple flag that asserts this key may only
be bound to the local-part of "postmaster" by convention, or _not_
bound to any specific header. This key should also cause the signing
domain to be marked as providing "limited" trust. In other words,
the content of the message has not be reviewed by the parent domain.
All this worry about header bindings is overlooking offensive
content, links, scripts, and executables.
Ironically, from a security standpoint using the "local-part" hides
the fact that this message should be treated with less trust. A
policy for a firm who wants to limit what a recipient trusts, may
assert a domain policy where messages must be signed by the domain of
the Originator Address. Perhaps they may also allow sub-domains that
are not bound to the Originator Address. For those that don't wish
to introduce problems getting their messages seen, may permit any
signer of the Originating Address.
Already, use of the Originator Address construct may confuse end
users who don't understand the OA rules, or who have a MUA that fails
to show the significant header. Once you assume that either mail
clients or MTAs will need to introduce visible information that
announce which domain is signing the message, then this key
distribution problem does not require specific local-part
restrictions. The true goal of DKIM should be to establish an
accountable domain.
Permissions based upon the OA:
- OA domain
- OA domain + "limited" OA domain
- OA domain + sub-domain
- OA domain + sub-domain + "limited" sub-domain
- any domain
Signed by sub-domain: big3-ad-agency.big-firm.com*
From: promotions(_at_)big-firm(_dot_)com
Users and content filters would know this could be any originating
address that contains any type of information permitted by big3-ad-
agency.big-firm.com. The "limited" flag on the signing domain would
also indicate there is even greater reason not to fully trust the
Originator Address or the message content for that matter.
The end-user's trust would be with ad-agency.big-firm*. The asterisk
could indicate this key is "limited" or rather it is a distributed
key. This would be a signal for the end-user to limit their trust in
the Originating Address as well as the message content. This would
not require investigating the OA binding policy. This will be a
common consideration made for most mail seen. This "limited" flag
still permits a means to publish domain policy to further ensure end-
users are protected, and yet ensure DNS performance remains acceptable.
These functions are are still on the same order of magnitude as
outbound signers or thereabouts.
You are assuming you know how this key will be used. There is
nothing to prevent abuse of this user component however, which could
lead to major problems. It may well become part of some wildly
popular application, such as a means to identify the end-user to web-
sites.
For true user level granularity down to
real individual users (eg, the affinity domain example), there a
significant
amount of work that would have to be expended first in order to
acheive
it: key management within the zone itself, web sites, trust
arrangements,
getting signing software on the user's MUA, etc, etc.
Offering free email accounts attracts customers. So will free user-
keys. The time for such deployment is not limited. Someone on this
list claimed that offering several gigabytes of user-keys would not
be difficult. Multiply that by a few hundred, thousand, or even
millions. : o
This won't happen
overnight -- especially in contrast to the relatively
straightforward job of
inserting a couple of selectors into the top level zone and
modifying your
outbound MTA.
Again, you are assuming you know how this resource record will be
used, while at the same time offering tags within the key to assert
what other undefined applications make use of this key. Before we go
down that road, we should consider what per-users key's impact may be.
So I guess I doubt that the DNS administrators are going to be
blindsided
by all of this.
I would rather not be making these assumptions. As I have often
heard, the IETF are not protocol police. They can help establish
policy, and for the most part, this policy should be implemented by
design. Once you allow the header to not be bound to the signer, the
compelling reason for per-user keys is dramatically reduced. With a
modicum of creativity, other simpler solutions could be found. I
even think there is a valid security argument NOT to allow per-user
keys.
-Doug