On Dec 22, 2005, at 8:38 AM, Keith Moore wrote:
If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.
My concern regarding the charter is related to inclusion of the SSP
draft, which can impose significant disruption. In my view, DKIM
should be seen as aspect of the SMTP transport. Having a signature
at the transport qualifies sources of email, but should not constrain
use email-addresses. Schemes related to the email-address such as S/
MIME or OpenPGP are designed to support email-address limitations.
On the other hand, DKIM purports to offer S/MIME or OpenPGP like
features for a sub-set of domains willing to disrupt normal email
practices.
The premise for DKIM protection assurances is based upon visual
examination of the email-address. This seriously flawed concept
already demands most MUAs change. Even the body-length option pre-
supposes there is some type of MUA modification. With DKIM sans SSP,
the MUA would be able to recognize prior correspondents without any
other exchange of information. In some cases, an MTA could use this
recognition to exclude some abusive traffic based upon prior
recognitions. The MUA should be able to safely signal source
recognition, but signaling adherence to some authorization would only
place recipients in peril.
SSP, just as with Sender-ID, requires email-address domain owners
authorize the source of their email, where signatures are transposed
for address lists. To allow existing practices, open-ended
authorizations are required. The danger from this approach has been
made apparent by those willing to hold any sort of authorization
accountable for abuse seen. There can be no promise that
authorizations can be open-ended to support existing practices.
Reputation schemes bolstered by having "authenticated" the identifier
when finding an authorization record will quickly preclude use of
open-ended authorizations.
When only a few domains publish the closed-ended authorization
records for SSP, looking for policy for the majority of email will
then require that label trees be climbed, where none of this effort
can be effectively cached. The solution for this rather broken
strategy is to create records that indicate open-ended authorizations
to mitigate the search. These nonsense open-ended records however
expose the email-address domain owner to unfair reputation schemes
already in place.
Details have been published for "compatible" extensions to DKIM that
improve upon source recognition, abating abusive message replay,
locating compromised systems, limiting the number of signatures per
message, establishing expectations for specific email-addresses being
signed, without requiring any additional lookups in most cases.
http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt
The WG should be limited to establishing the base DKIM signature.
This signature should be viewed as an aspect of the SMTP transport to
differentiate it from S/MIME and OpenPGP. Another WG should make
efforts related to the MUA incorporating the protections offered by
DKIM in an opportunistic fashion. In essence, everyone becomes their
own certificate authority based upon individual email source
identifiers offered by DKIM. Recipients would be able to confirm the
validity of the correspondent through out-of-band identifications of
the source. This could be simply an expected confirmation when
initially establishing a relationship. Once the initial identifier
has been accepted by the recipient, messages could be safely
highlighted as coming from a recognized source.
There can never be a safe indication based upon a domain used in the
email address as having authorized the message. There must be more
consideration given for the use of unicode. One only needs to
investigate the number of look-alike characters in Chinese to
understand the fallacy of that assurance. Even the individual that
does not understand the difference between online.bigbank.com and
online-bigbank.com could be protected by a recognition scheme.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf