W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

Re: Passphrases in or out

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Wed, 07 Aug 1996 16:41:40 -0700
Message-Id: <199608072341.QAA19704@work.ucsd.edu>
To: Steve Petri <petri@litronic.com>
cc: ietf-tls@w3.org
Hi Steve,

Allowing the implementor to to bad things is different from allowing
the -user- to do bad things.  Even with assymmetric cryptosystems, the
user may publish his/her private key (or encrypted private key along
with the decrypting passphrase) -- an obvious Bad Thing.

The -protocol- can not prevent that.

The point about having a protocol design so that implementors can't
easily hang themselves -- I'm one of the people who advocate this
position, much like high level languages etc -- has to do having as a
result an overall system that do not have holes; users can hose
themselves by creating individual holes, but that does not necessarily
cause the system to fall as a whole.

It's still valid to argue that we do not want to permit the user to
easily hang him-/herself.  This is a slightly different argument,
however, than the one that I (and others) had made at Montreal.

Is there enough user education so that they won't chose bad passwords?
So that they won't disclose their private key?  So they won't run
trojan horse, virus-laden software?  The list of possible bad things
that a user can do goes on and on.

I think that since the system implementor choses the web server
configuration (or other server) to permit or disallow passphrases at
the protocol level, and the system implementor can decide (has the
rope) whether s/he can educate his/her users enough about passphrase
selection, having this option won't hurt.  It is better than forcing
some systems implementor to do passphrases on top of weak encryption,
which is the current practice.  For banks and stock brokers.

--------

Regarding the proposal to provide multiple channels with different
crypto strength, I'd be happy if it really is exportable.  Granted, if
I were a spy, I'd type "attack at dawn." in the 16 character field for
my credit card number in a form that will send the (purported) credit
card number via the more secure channel.  (Web form provide by a
server run by my collaborator/controller overseas, say.)

This is not to say that this kind of more secure communication isn't
possible with the passphrase hash mechanism.  For example, one could
use a code book of passphrases, so that the server would hash using
all possible passphrases in the code book to find one that matches and
lookup the corresponding meaning therein.  Longer messages can obvly
be done by constructing an alphabet out of the passphrases, and
iterating the authentication protocol.  A tad clumsier at the server
end since off-the-shelf server software can't easily be used, but not
horrible.

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114
Received on Wednesday, 7 August 1996 19:42:09 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:51 EDT