Jim,
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Monday, November 21, 2005 10:32 PM
To: Jim Schaad
Cc: 'IETF DKIM WG'; fenton(_at_)cicsco(_dot_)com
Subject: Re: [ietf-dkim] Comments on the Threat Draft -
draft-fenton-dkim-threats-01
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 realize that I am not the first to suggest this, other people than Stephen
have also done this. I think that Russ was hasty in permitting this to go
forward based on this document, indeed I believe that I have a clearer
picture from talking to participants (such as Jon Callas) than from reading
this document. I just wish that everyone had the same basic picture and a
document would do this.
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.
A good starting point -- I need this so that I can understand what people
are talking about half the time.
-- 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.
That would be sufficent -- even if its not RFC bound, providing that it
covers all of the entities that you think you need to talk about and gives a
good model (sorry Dave, I have not looked at this document yet).
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.
I agree that this is not really distingishable, I was just trying to deal
with the difference between mail from certain individuals that I deem
unwelcome vs "spam" which is too undefined of a term. Unsolicited bulk mail
is well understood as a term by anyone of us.
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?
Non-DKIM items are messages that do not have DKIM signatures.
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.
I'll let Stephen have his perferences, I don't see the need for full
descriptions everywhere. I want to be able to hand this document to my boss
and say "This is why the effort is important" and too much detail is
determental to this usage.
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.
I am willing to have different items have different amounts of detail here.
I think that SSP is easier to understand (but harder to get correct) than
DKIM is, thus the justification to do it could easily be placed in the SSP
document. I think that the justification for DKIM is more difficult to
understand without the additional items of other way it might be used.
Jim
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org