On Jul 29, 2005, at 6:38 AM, <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>
<domainkeys-feedbackbase02(_at_)yahoo(_dot_)com> wrote:
It's always amused me that the format of the bits is excruciatingly
important,
but how often I send them, where I send them (assuming willing
recipients,
thank you Andy) and how the whole internet may have to morph and
compensate as
a consequence, is entirely a private decision.
Which is what makes this thread amusing. We sometimes constrain
ourselves with
self-imposed limits that should be seriously challenged from time
to time.
Sometimes one should challenge a lack of constraint from time to time
as well.
DNS supports many applications beyond email. In addition to the
cache, DNS also relies heavily upon UDP, which may induce problems as
UDP's relative traffic increases. DKIM is doing many things right,
when compared against other schemes attempting to use DNS to confirm
accountable domains. Resist a desire to add features beyond this
immediate goal of confirming an accountable domain.
DNS is not an infinite information sponge. When increasing the
number items stored in DNS, especially when these items are
relatively large and used by potentially millions of domains, this
will increase the DNS cache needed to obtain the same performance and
stability. When a change is incremental, and offers a relatively
linear growth as the mechanism becomes employed, then administrators
have time to adjust.
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.
When the potential resource required to support cryptographic user
confirmations within DNS is considered, I suspect there should be
policy adopted that specific key servers should be used to support
users, solely as a means to ensure the performance of DNS. DKIM can
avoid this problem by practicing a self-imposed commitment to a
specific goal of confirming just the _domain_.
There can be many more users than actual individuals. DNS normally
supports servers often shared by thousands users. The number of
shared users can increase as server performance increases. When a
similar amount of DNS resource is consumed to support each user, this
will dramatically counter the effects of this trend. Attempting to
confirm _users_ using keys stored in DNS is not an incremental
change, rather it has the potential to cause an explosion in DNS
use. It is also likely other applications (even accommodated in the
DKIM draft) will attempt to take advantage of such user components as
well, which will ensure that should this user component become a
problem, it will then be an intractable situation.
Even how domain policy is handled affects the impact that DKIM has on
DNS resources. Thwarting the spoofing of a domain requires the
validation of the signature and exposing the signing domain to the
end user and perhaps a reputation evaluation. Binding constraints
imposed by the "From" domain will remain problematic. Using DNS to
publish such binding policy, where each node is allowed to change,
represents an attempt to transform DNS into a directory structure,
rather than treating it as a label tree.
Focus upon the one goal, confirming the accountable domain. To even
further challenge the focus of DKIM, ignore binding policies,
permitted third-party domains, along with permitted local-parts. A
domain policy may safely assert that all messages received directly
from this domain along with all sub-domains are signed. Leave the
rest as second semester work. I suspect by then there will be other
issues that become far more pressing. Keep it simple for now.
-Doug