[ietf-dkim] Comments on the Threat Draft
fenton at cisco.com
Mon Nov 21 22:31:44 PST 2005
Jim Schaad wrote:
>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
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,
>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
>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.
>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.
More information about the ietf-dkim