On Tue, 2005-09-27 at 20:56 -0700, Jim Fenton wrote:
The threat analysis is really a requirements document. It neither rules
in or rules out the use of things not currently in the DKIM
specification, such as revocation identifiers or SSP alternatives,
because these are choices that might be made in the design phase.
Threat analysis should not overlook or dismiss deficiencies. Issues
raised were specifically in regard to elements lacking in the current
draft's threat response. As described, these are not extensive
modifications. Nevertheless, integrity of the defense should be more
prominent in a threat analysis and a requirements document.
Actually this document goes somewhat beyond a pure requirements document
because it does discuss the effectiveness of a particular existing
design, dkim-base-00 and dkim-ssp-00, in responding to these threats.
This is intended to illustrate the approximate effectiveness of
something that approximates DKIM, to show (hopefully) that it does
something useful and is worthy of the formation of a working group. It
is not intended to preclude further improvement of the specifications.
SSP requires considerable support and overhead introducing mailbox-
domain authorization registrations. Contrast either rigid or open-ended
mailbox-domain authorizations to bindings of correspondent identifiers
directly obtainable from signed messages. In addition, mailbox-domain
authorization includes risk where reputation accrual may be unfairly
based upon exploitable authorizations. Either choice of a rigid or an
open-ended authorization scheme reduces email delivery integrity.
While considering effective responses to threats, DKIM should also
strive to reduce costs incurred by recipients to ensure successful
deployment. Reduction of collateral blocking represents a cost savings.
Reduction in reliance upon third-party reputation or filtering services
would be another. In addition to providing an effective threat
response, there are cost benefits derived from inclusion of an opaque-
identifier and a responsive opaque-identifier revocation mechanism.
Without ensuring effective defenses against expected threats, reputation
of the sender becomes worthless and DKIM can not be sustained. Reliance
upon third-party filtering services would not be a compelling. Support
issues when changing normal practices would also risk deployment.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org