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
