- From: Dan Simon <dansimon@microsoft.com>
- Date: Fri, 2 Aug 1996 17:15:31 -0700
- 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 UTC