Jim, > -----Original Message----- > From: Jim Fenton [mailto:[EMAIL PROTECTED] > Sent: Monday, November 21, 2005 10:32 PM > To: Jim Schaad > Cc: 'IETF DKIM WG'; [EMAIL PROTECTED] > 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
