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

Re: Repost of CompuServe Position on Passphrases

From: Taher ElGamal <elgamal@netscape.com>
Date: Fri, 02 Aug 1996 13:22:57 -0700
Message-ID: <320263A1.2E62@netscape.com>
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 EDT

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