On Sep 28, 2005, at 7:40 AM, Arvel Hathcock 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.
Yep, exactly correct. Let's focus now on perfecting this threat
analysis document and leave matters of "DKIM doesn't have this" and
"DKIM needs to stop doing that" for later.
I too wish to see DKIM move forward. However, lacking a realistic
assessment may weight against receiving the endorsements for moving
forward.
While the latest version of the DKIM draft itself is a substantial
improvement over preceding drafts, what problem is being solved and
what threats are avoided?
The abstract for DKIM makes the following statements:
,---
| The ultimate goal of this framework is to prove and protect message
sender
| identity and the integrity of the messages they convey, while
retaining the
| functionality of Internet email as it is known today. Proof and
protection
| of email identity, including repudiation and non-repudiation, may
assist
| in the global control of "spam" and "phishing".
'---
There should be a description in the threat analysis regarding what
identity is or is not protected. As example, consider the provider
offering outbound email services as a third-party signer. This
provider permits any and all mailbox-addresses, but promptly
terminates abusive accounts. A normal practice. This permissive
acceptance of mailbox-addresses retains the functionality of email
today.
How is the signing-domain (the relevant identity with respect to
DKIM) protected? How is repudiation realistically achieved in
response to a replay attack in this scenario? Does a lack of
effective repudiation prevent reputation being a basis for
acceptance? In other words, does a lack of effective repudiation
with the loss of a reputation utility substantially degrade possible
"spam" or "phishing" deterrents?
When attempting to extend protection to other identities, is SSP
mailbox-domain authorization easily exploited? What are the attacks
that defeat this authorization approach?
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org