[Prev][Next][Index][Thread]

Re: STLP and proposal

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
References: