RE: IAB draft on security

(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 Monday, 26 July 1999 12:24:01 UTC