- From: Geoff <geoffm@redconnect.net>
- Date: Tue, 27 Jul 1999 04:43:44 -0400
- To: "'Dave Crocker'" <dcrocker@brandenburg.com>
- Cc: "'smb'" <smb@research.att.com>, "'IETF Apps'" <discuss@apps.ietf.org>
I think the cookbook is an excellent suggestion. And as I also believe that for messaging it's time to dump both PGP and S/MIME in favour of something much simpler to implement, maybe the cookbook could outline an alternative. Geoff (Thanks to Paul, for starting this ver important thread.) The current draft is wonderfully concise and readable. For the non-expert, it is an excellent way to learn both about the current range of standard (and non-recommended) techniques and some issues about their uses. I think it needs more, not different, text. At 06:24 AM 7/26/99 , Geoff wrote: >1) Mostly much too complicated and time consuming for the average user to >set up and use. >2) Confusion caused by competing standards S/MIME vs PGP. >3) Confusion caused by US gov interference. >4) Confusion caused by licencing and patent issues. Nice list of possibilities. They do not all have the same import. I think that the complexity of "valid" security mechanisms (by which I mean mechanisms that have real-world effectiveness, for the level/quality of security promised) is very hard to design. That is a technical limitation, within the technical community. It is best demonstrated by the constant ping-pong IETF process of having applications folk try to design a mechanism and having security experts shoot it down. Possible guidance for Bellovin's paper: Add a section 7, with recommendations for entire security "systems" to be used for particular scenarios. Yes, this is requesting the cookbook approach that the document specifically warns against, but I have long felt that we have no choice. Show some very common application environments and recommend a specific SET (no pun intended) of tools, based on the protections needed. (Start with application or connection type, move to protection type, then list techniques recommended.) Frankly I view this as a human factors problem. We need to make it easier to use these technologies. Use by protocol designers, as well as use by sysadmins and end-users. In other words, I think that the REAL barrier to security use is variations on Geoff's #1. #2-4 affect quality of use and effectiveness, but I do not believe they are the real "market" barrier. For now, it is very difficult for non-experts to design protocol services that the security experts approve. The cookbook should attack (pun intended) that problem directly. However, it is also very difficult to install and run a security service. The choices made for the document should reflect easier/harder operations. And end-users trying to set up their security environment, such as for PGP or S/MIME, are usually hit with far, far too much complexity. (It does not help that the security module is often an add-on, rather than built-in.) We can't do anything about end-user complexity, other than try to raise the issue for developers, unless there are specific implementation suggestions we can offer than will make things simpler. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +1 408 246 8253 Brandenburg Consulting Fax: +1 408 273 6464 675 Spruce Drive <http://www.brandenburg.com> Sunnyvale, CA 94086 USA <mailto:dcrocker@brandenburg.com>
Received on Tuesday, 27 July 1999 04:43:47 UTC