W3C home > Mailing lists > Public > ietf-discuss@w3.org > July 1999

RE: IAB draft on security

From: Geoff <geoffm@redconnect.net>
Date: Tue, 27 Jul 1999 04:43:44 -0400
Message-ID: <01BED7EA.B75E9220@cdm-10.sub8.nyc.redconnect.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:26 GMT