On Sep 7, 2006, at 10:20 AM, Thomas A. Fine wrote:
Ok. There's a few reasons why we've been told we need this, and
they're all wrong. Let's take a look at each of them:
1. Provide the ability to transition a domain, where part is ready
and part is not.
This would not be a problem unless one assumes policy can only be
applied domain wide.
2. Provide the ability to only sign important addresses.
Or sign all messages and apply different policies based upon email-
addresses.
These can be handled by "I sign some mail" (or perhaps just as well
with no policy at all). Then the company can sign only the mail
they want to sign.
This affords no protections beyond there being no policy asserted.
In both of these first two cases, there is an assumption that it
will be hard for bigbank.com to get to the policy of "I sign all
email", and we should accomodate them. Granted it's hard. But we
should also be able to assume that it is worth it, and that "I sign
all" is the desired long-term situation.
Without a means to differentiate policies based upon email-addresses,
employees of BigBank.com participating in mailing lists need to use a
different email-address domains. Unless all employee's email-
addresses are changed, BigBank.com remains exposed to the possibility
of poorly vetted messages being signed without a means to adjust
assurances being implied by a trusted domain list.
A half-covered domain leaves that domain severely exposed. Suppose
bigbank.com signs for "accounts", "statements", "president", and
"investment". They would also have to try to exhaustively cover
for 1000 legitimate looking variations on those addresses, as well
as 10000 legitimate looking addresses that don't look anything like
the real ones, and almost certainly miss something, and leave
themselves open to phishing, anyway. All despite the fact that
they tried to do something that is in many ways more complicated
than full coverage.
When DKIM related annotations are always expected by the recipient,
there would be zero concern related to look-alike attacks, as these
messages would not obtain these annotations. These annotations could
be based upon an email-address being found within the address book,
or within a trusted domain list in conjunction with email-address
assurances made by way of policy.
100% coverage may be hard, but it is necessary to protect a domain.
Half-assed coverage is useful transitionally, that is all.
Subdomains are another mechanism by which bigbank.com can split up
their transition, and protect the most important addresses first,
although again, without complete coverage you can have similar
problems.
100% coverage will not protect the domain. There remains the problem
of look-alike and cousin domain attacks. The only tenable protection
available would be based upon recognized email-addresses found within
the address book or domains listed as being trusted. Even when the
domain is listed as being trusted, policy can play a vital role in
identifying which email-address the domain asserts as appropriate for
high level assurances.
3. Provide the ability to sign all addresses, but offer different
strengths of signatures, ranging from "this came from us" to "we
absolutely certify the accuracy of everything in this message"
I'm trying to make sense out of this. I'm not sure I see it yet.
What good does it do to give a particular address it's own key if
you're already signing everything? Is there some proposed
mechanism for quality assurance ratings as a part of DKIM?
Although there is always the wonders of web-mail. : (
A sales person or executive may wish to obtain their own email-
address restricted DKIM key. This would allow them an ability to
sign messages without needing to obtain direct access to the
corporate servers, which may be blocked by hotel firewalls for example.
I suppose one case might be the disgruntled bigbank employee who
starts generating fake messages from [EMAIL PROTECTED] That's
an internal matter for bigbank, and it isn't our job to fix this
problem. Internally, there's dozens of ways for them to secure
important addresses, including software that requires extra
verification for certain addresses, or use of subdomains to
partition off everyone from mid-management on down.
BigBank may indeed prevent abuse of the [EMAIL PROTECTED] email-
address. However, don't assume the recipient even sees this
addresses. They may be viewing only the display name. This issue
must consider how the message is annotated. Without annotation DKIM
is absolutely worthless at preventing any type of spoofing. With
annotation, DKIM can preventing the all too common spoof.
But ultimately, no scheme can completely prevent this from
happening. What if the guy that maintains DNS is the one that's
disgruntled?
One could presume that someone administering their system has been
well vetted. A sale's person's laptop or a temp worker may represent
something far less trustworthy.
4. Provide the ability for users outside of a domain to send mail
from within that domain.
External access is not be the issue raising the concern. All
messages being signed still leaves an array of possible messages from
mailing lists and e-invites etc. There are too many domains for safe
annotations to be created on a per domain basis without some
assistance from that domain. Allow them to indicate which email-
addresses should be treated harshly, or provided high level assurance
annotations.
Again, it's not DKIM's job to solve the internal problems of a
domain, especially when those internal problems are so easily
solved otherwise. VPN is one solution, so widely available that I
can run it on my palm.
Policy offers a means to better protect recipients of their
messages. It has nothing to do with internal problems. What is
being described is fairly normal. Not everyone within an email-
address domain are equally trustworthy. Allow policy to assert
different levels of assurance for those messages where only the
domain itself is being trusted. In other words, recipients don't
already know the specific From email-address, they just trust the
domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
