Jim Schaad wrote:
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.
Regardless, it seems like it was adequate for the purposes of answering
questions related to chartering the WG, and we have an opportunity to
reorganize it now. This is the second suggestion on organization; see
also Stephen Farrell's message of October 12,
http://www.mipassoc.org/pipermail/ietf-dkim/2005q4/000724.html
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:
We'll need to reach a consensus on text of this sort for all the
documents to use. I want to make sure that the threat analysis is 100%
consistent with the other WG documents in this area, preferably by using
the exactly same text.
-- 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.
Good point.
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).
Another way to do this is to make a reference to a document such as
draft-crocker-mail-arch, provided that document is RFC-bound by then.
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
I'm concerned about this one. DKIM operates on single messages, so
"bulk" is not relevant, and it has no way of distinguishing solicited
from unsolicited traffic.
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.
So, effectively, this becomes a threat analysis of -base only, which
many consider to be incomplete if used in isolation. Are you suggesting
a separate threat analysis document describing -ssp, or are you hoping
SSP just goes away?
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.
What do you mean by a non-DKIM item?
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.
Stephen has indicated a preference on having the attacks described in
both places, even if it is repetitive.
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.
As others have pointed out, treating SSP (a WG deliverable per the
proposed charter) and reputation services (out of scope per the proposed
charter) in the same manner seems inappropriate. My strong preference
is to include SSP in this threat analysis and not to discuss reputation
(or accreditation) services other than perhaps to mention that they
might be users of DKIM.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org