- From: Taher Elgamal <elgamal@netscape.com>
- Date: Tue, 23 Apr 1996 20:05:55 -0700
- To: Dan Simon <dansimon@microsoft.com>
- Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
I only mentione these two not as a complete set at all. The working group should consider all possible features, improvements and enhancements. My message was sent because the "private" STLP discussions became public very quickly and I do not see the need to discuss these things twice, once in one-on-one and once in the WG. My opinions about some of the proposed features do not reflect what the WG would like to do or otherwise propose. I just noticed that SSL3.0 looks like a good starting point, and if we start now we have a chnace of getting somewhere. Taher Dan Simon wrote: > > > > >This is in response to the mailings and press announcements exchanged > >regarding the Microsoft proposed modifications to the SSL 3.0 > >specifications -- apparently referred to in the industry as "STLP". > > > Taher addresses only two technical points: datagram support and support > for pre-encrypted data. The former, while certainly not the *main* > function for a TLS protocol, is useful for such purposes as sending > out-of-band data, and for protocols like PPTP, which establish a TCP > connection for control messages but use IP for bulk data transmission. > Taher claims that the mechanism proposed for the latter (pre-encrypted > data) "breaks" the protocol, but I don't see that it poses any security > (or other) problems. (If it does, I would certainly like to see the > details.) In the absence of such problems, I believe that support for > pre-encrypted data would be a useful efficiency feature of the protocol. > (I might add that there are most probably other ways of implementing > the feature safely, if use of the "change cipher spec" message is > unworkable.) > > There are a number of other technical issues raised by the STLP document > that I believe merit consideration. The most salient is the possibility > of revamping the handshake protocol flow to make it more flexible, > symmetric and efficient. Another is that the negotiation of > authentication options can be made more flexible and explicit by > including, for example, certificate types and the option of > password-based authentication. (This latter topic has already been > raised by David Kemp, who opposes the inclusion of the password option, > and has also commented on some of the other technical issues; I'll > respond to his points as soon as I can.) > > 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 Tuesday, 23 April 1996 23:02:16 UTC