On Oct 21, 2005, at 12:51 PM, Dave Crocker wrote:
I understand there is a desire not to introduce many more things
or drive the spec in new directions, and I agree with that.
Having said that, it is better to make any changes now while
adoption is low than wait until adoption is much higher.
On the other hand, doing more work takes more time. More time
means more delay getting more adoption.
In fact I have been getting a sense of some folks delaying adoption
until the IETF standard is produced.
So the question is whether we want that to be 2006 or is it ok to
be 2007, 8, ...?
I understand this concern, however DomainKeys ran into an adoption
problem as a result of unintended support issues created by email-
address/header constraints that limited needed freedoms. DKIM/SSP
unfortunately creates similar problems with respect to being able to
assert all email is being signed. (This assertion allows repudiation
of unsigned email or email signed by other domains.) Until a domain
signing assertion is compatible with RFC-2822, the same support/
deployment issues also threaten early adoption.
There will be email lost as a result of third-party assertions, as
SSP is not compatible with RFC-2822. While protecting the From
header has merit for a few cases where only two-party communication
is desired, this From/Sender assertion should apply to _all_ possible
parameters and headers that may indicate where the message
originated. For conventional multiple-party email, being able to
assert that all email is signed should be premised upon RFC-2822
conventions. The current strategy for SSP means that some mail must
be expected to go missing unless emails are encapsulated as a means
to remove possible problematic headers. Such a change will happen
when and accomplishes what?
While the current SSP effort is an attempt to protect visible
headers, it comes with a high cost with respect to support caused by
service disruptions well beyond the control of the signing-domain.
SSP does not provide adequate protection for MUAs that display the
"pretty name" or that fail to display the Sender, or that display the
Sender as the significant header. There is also the risk that
multiple From email-addresses may not be properly displayed, or could
be obfuscated in a manner that confuse the recipients. There remains
the problem with "look-alike" domains.
Non-compliant SSP assertions will greatly slow deployment when a
domain can not safely declare only they sign all their email.
Without such assertions being possible without also having to permit
other domains an ability to also sign their email, DKIM fails to
provide the advertised protections. This lack of protection will
thwart early deployment once an initial experience demonstrates DKIM
to be both costly and disruptive, while failing to offer substantial
protection.
DKIM without SSP, and perhaps a few binding hints and identifiers
securely included within the signature header, may offer superior
protection within a much shorter timeframe. This could include
protection that signals the presence of similar "pretty names" and
"look-alike" domains based upon bindings stored for prior
correspondents. The current SSP strategy depends upon establishing
authorized third-party signing-domain lists and perhaps even path
registrations. Such authorization lists are risky and an
administrative nightmare. I suspect one reason that DKIM has stalled
is from a desire to see a comprehensive solution. In my view,
devising a strategy able to defend the reputation of the signer is
the task that lies ahead. Minimizing the upgrade efforts should be
secondary, although not dismissed. Fortunately the current
DomainKeys design is extensible.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org