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

RE: Repost of CompuServe Position on Passphrases

From: Don Schmidt <donsch@microsoft.com>
Date: Fri, 2 Aug 1996 17:29:13 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-86-MSG-960803002913Z-5734@tide19.microsoft.com>
To: Dan Simon <dansimon@microsoft.com>, "'elgamal@netscape.com'" <elgamal@netscape.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Christopher Allen'" <ChristopherA@consensus.com>

But then the application has to provide the encryption, make sure it can
only be applied to auth data and not bulk user data, become involved in
key management...

From a service perspective, the purpose of a standard security provider
at the systems level is to offload these functions from applications.
From a security perspective, it is to make sure they are provided in a
consistent, robust manner.

If it is good to provide this support to applications for certificates.
Then why is it not also good to provide it for shared-secrets?

Don Schmidt
Program Manager
Microsoft Corp

>From: 	elgamal@netscape.com[SMTP:elgamal@netscape.com]
>Sent: 	Friday, August 02, 1996 1:22 PM
>To: 	Dan Simon
>Cc: 	'ietf-tls@w3.org'; 'Christopher Allen'
>Subject: 	Re: Repost of CompuServe Position on Passphrases
>Exportable applications are allowed to encrypt passwords with any bit 
>Dan Simon wrote:
>> >
>> >From:  Christopher Allen[SMTP:ChristopherA@consensus.com]
>> >
>> >I don't see how not having this feature prevents CompuServe from creating
>> >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.
>> >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
>> >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 20:32:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC