http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
CompresssionMethod
as values in the range 193 to 255 are reserved for private use.
Where does the above draft state that the dictionary must be reset?
It states that the engine must be flushed but does not indicate that
the dictionary is to be reset. Resetting the dictionary would turn
ZLIB into a stateless compression algorithm and according to the draft
ZLIB is most certainly a stateful algorithm:
"the compressor maintains it's state through all compressed records"
I do not believe that compatibility will be an issue. It will simply
result in the possibility that the compressed data is distributed
differently among the TLS frames that make up the stream.
If compatibility is a issue we could implement a new variant of
COMP_zlib(); COMP_tls_zlib() that would be used with ZLIB(1).
> Well, I've got a couple of issues with such a change:
>
> 1. Is OpenSSL really the only implementation that has ZLIB at all? I
> believe there aren't any compression numbers defined for ZLIB yet
> (are have they actually been defined by now?), so I guess it might
> be tricky to implement in any case...
> If OpenSSL isn't alone with ZLIB compression, perhaps we should
> look at interoperability?
>
> 2. How does that affect communication with programs running older
> versions of OpenSSL? I assume that a change in dictionary reseting
> will also change the actual data that's resulting from compression.
> Will that be a problem?
>
> --
> Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
> \ SWEDEN \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
