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

RE: Repost of CompuServe Position on Passphrases

From: Dan Simon <dansimon@microsoft.com>
Date: Fri, 2 Aug 1996 17:15:31 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-92-MSG-960803001531Z-12733@tide19.microsoft.com>
To: "'elgamal@netscape.com'" <elgamal@netscape.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Christopher Allen'" <ChristopherA@consensus.com>
>
>From: 	elgamal@netscape.com[SMTP:elgamal@netscape.com]
>
>Dan,
>
>Exportable applications are allowed to encrypt passwords with any bit 
>length.
>
Of course, but where does the encryption key (not to mention the
encryption algorithm) come from?  The whole point of the TLS handshake
is to solve the messy, difficult problems of channel encryption and key
exchange once and for all, for every application.  If the resulting
"exportably secure" channel cannot be used by the application for strong
encryption of passwords, then the application will have to establish its
own (truly) secure channel for passwords at the application layer.  Once
it's doing that, it might as well just handle all the encryption and key
exchange itself, ignoring TLS altogether.

Presumably, though, we want applications actually to use (possibly
exportably implemented) TLS  for their channel security--including, if
necessary, password encryption.  In that case, the (exportable) TLS
implementation has to distinguish between bulk data (exportably
encrypted) and the password (strongly encrypted).  Hence the need for
special treatment of passwords in TLS. 


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com
Received on Friday, 2 August 1996 20:18:09 EDT

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