STLP "implementation comments"

Some of the comments in the STLP draft are misdirected and have confused
at least one implementor of SSL 3. The responses below are only here to
remove confusion about the SSL spec. No inference should be made about
agreement or disagreement with any other part of the STLP spec or the
implementation comments.

> SSLv3 Implementation Comments
> 
> The following non-comprehensive list is derived from implementation
> experience with SSL Version 3 published as an Internet Draft in March
> 1996. Its intent is to suggest modifications to the base protocol
> rather than to specifically critique SSL Version 3. 
> 
> (1) There is no significant implementation cost for separate
> negotiation of the message digest algorithm and the bulk cypher.
> In fact, the code could be better if they were separate; instead
> of one large table with a lot of repetition between entries there
> would be two small tables with no repetition.

There is no API or implementation implied by the SSL 3 spec. In fact,
the Netscape implementation is done with mutliple small tables. 

> (2) Don't use post-compressed, post-hashed, post-encrypted,
> post-enveloped data for the final handshake digest. Implementation
> is painful. Using the original cleartext, or alternatively, the
> compressedtext, makes for a cleaner layer structure in the
> implementation.

The handshake hashes are done with the plaintext input of the handshake
data. A straightforward implementation is possible without any layering
violations.

> (4) Provision for a uniform message header for all types of messages
> is a very good thing. At any time in the process it should be
> possible to differentiate control from client data.

Since there are 4 sub-protocols on top of the SSL record layer
(application data, alerts, handshake, change cipher specs) it is already
possible to the differentiation.
 
> (7) Greater symmetry would be valuable from an implementation point
> of view. If a given piece of data is being exchanged, it should be
> the same whether the server or the client is supplying it (there
> should not be two different message formats for supplying a
> certificate). Right now, implementing the server and implementing
> the client are almost unrelated tasks because the protocol is so
> asymmetrical.

The final SSL 3.0 protocol was influenced by its implementation. Much
sharing is possible betweent the messages dealt with by the client and
server. (For instance, The Certificate message is the same independent
of direction.) Many messages contain common sub-records.

> (8) MD2 and MD4 need to be phased out owing to the detection of a
> security problem. SHA is recommended. 

SSL 3.0 does not use MD2 or MD4.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://home.netscape.com/people/karlton
Netscape Communications

     They that can give up essential liberty to obtain a little
     temporary safety deserve neither liberty nor safety.
		- Benjamin Franklin

Received on Wednesday, 24 April 1996 12:52:53 UTC