- From: Taher ElGamal <elgamal@netscape.com>
- Date: Fri, 02 Aug 1996 13:22:57 -0700
- To: Dan Simon <dansimon@microsoft.com>
- CC: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Christopher Allen'" <ChristopherA@consensus.com>
Dan, Exportable applications are allowed to encrypt passwords with any bit length. Taher Dan Simon wrote: > > > > >From: Christopher Allen[SMTP:ChristopherA@consensus.com] > > > >I don't see how not having this feature prevents CompuServe from creating a > >secure, server authenticated channel, then using their existing password > >infrastructure to then authenticate the client. I can do this today with > >SSL under FTP, NNTP and without certificate-based client authentication. In > >fact, many of our prospective licensees of the SSL Plus toolkit plan on > >doing just that. > > > >Tell me something that CompuServe can't do without this feature, and I > >might be more in favor of it. > > Okay, here's one thing: they can't protect password-based > challenge-response transcripts with strong encryption while adhering to > export restrictions. If the application is restricted to exportable > encryption, then it can't properly protect challenge-response pairs from > brute force attacks--first against the encryption, then against the > password. > > >But adding a password feature to a > >certificate based protocol where it doesn't fit invites security holes and > >poor implementations. > > ....As does *not* adding the feature, if the result is that most people > simply stick with application-level password authentication. > > > >BTW, I don't buy the reasoning "but now shared secrets will be done in a > >standard way under TLS". If everyone is going have to change things so that > >it is done in a "standard way" to support passwords under TLS, they might > >as well change it so that they use certs. > > I'm hardly an implementation expert, but my impression is that there's a > huge difference between having to "change things" and converting to an > entirely new security architecture and client authentication > infrastructure. If the only way to "change things" is to do the latter, > then I fear that few will bother to change at all. > > Daniel Simon > Cryptographer, Microsoft Corp. > dansimon@microsoft.com -- Taher Elgamal elgamal@netscape.com Chief Scientist, Netscape Communications (T) 415 937 2898, (F) 415 428 4054
Received on Friday, 2 August 1996 16:23:21 UTC