Jim,
I have some comments on this draft that I would like to make.
I am not happy with the overall organization of this document. It does not
fulfill my expectation of what I belive that Russ asked for, and perhaps
more importantly it does not help me understand the problem and solutions
involved.
I would suggest following outline for the document:
A. Introduction - provide a brief explication of the problem(s) that the
DKIM group is suppose to solve. I would suggest something along the lines
of the following:
"Given the lack of security properties which were designed into the current
RFC 821 mail system, a recipient of a an email message cannot reliably
determine any information about where the message originated or who sent the
message. If a solution to this problem is created, recipients could using
the origination information along with additional information such as
locally-maintained whitelists, shared reputation services and/or third-party
accreditation to filter out messages which either 1) did not come from the
purported originator or 2) originated from an originator that has
demonstrated bad characteristics in the past.
Given the current constraints of usability and roll-out of message sender
based security, this document looks at solving the problem by the use of
domain based signatures. In this model, the signature is applied to the
message by those system agents (such as MSAs (message submission agents) and
MTAs (message transmission agents)) which inject the mail into the delivery
system (i.e. the internet).
We will not be looking at the questions of message confidentiality or
long-term archival of messages."
-- I think that the reference to the base document should be removed. You
want to publish this document first so you don't want a reference to an
unpublished document.
B. Terminology and Model - Define the entities (or roles?) in the model,
provide a picture of the model
Examples of terms: MTA, MUA (automated vs human interface), Gateway,
Administrative Unit, MSA (message submission agent), Mail Server (what ever
a POP or IMAP server should be termed), MLA (mail list agent).
I think that you should potentially outline the difference between 2822 and
2821 solutions in this section as well as this seems to be very popular on
the list at the moment and is not necessaryly clear to everyone on the list.
C. Provide a more detailed description of the threats and bad actors. This
can be done with the terminology from section B. The set of threats
outlined in the current document and on the list should be covered. This
includes defining the threats and providing standard names so that we can
start agreeing on what we mean when we say "spoofing" for example. The
description of the attacks should include the various places in the model
that the attack could be launched from.
Unsolicited bulk mail
Spoofed mail
D. Description of the solution that DKIM is providing. This needs to be
restricted to what is being placed in the base document (thus would not
include SSP). This section should specify which of the attacks from C are
covered by this solution and which are not covered by the solution.
1. Digital signature over some fields and body
2. Signature is applied by ?
3. Signature is verified by ?
4. Potential actions on siguture verification failures
5. Key distribution methods (may be generic if DNS is used as that
would not be documented in base)
6. How non-DKIM items would be expected to be dealt with.
E. Generic description of attacks on DKIM. The specfic descriptions should
be placed in the base document and no in this document. This makes it
easier for readers and implementers of the base document to understand what
things they need to be worried about as there is only a single document for
them to deal with rather than two.
1. Signature failures
2. Key Distribution system failures
3. Partial Adoption Attacks
4. Mail List attacks
F. Potential Extensions to the base document (I would prefer this to be
labeled as appendix rather than section of the document for clarity). This
would include such things as SSP, reputation services and other items.
Jim Schaad
_______________________________________________
ietf-dkim mailing list
http://dkim.org