Subject: Re: Compressed data type for S/MIME

From: [email-masked] (Peter Gutmann)
Date: Tue, 3 Aug 1999 01:12:30 (NZST)

Dean Povey <[email-masked]> writes:

>SSL/TLS has built in compression support as part of the protocol, but this
>has been slow to come to market.  Why?  One of the reasons has been that
>you want to turn compression on and off depending on the underlying content
>(e.g. if it is a GIF or JPG or .gz etc, don't compress).  

zlib already does this transparently, it won't try to compress uncompressible
data (try running zip on a mixture of text and (say) other zip files, when it
says "Storing (0%)" it's generally zlib making the decision for you).  For 
SSL it's rather different because you've got an arbitrary stream of who 
knows what rather than individual files like zip or CMS.

I think the real reason compression in SSL is been slow to come to market (and
the reason it will probably never be supported even though it's defined in the
spec, and OpenSSL nee SSLeay has supported it for some time) is because the 
original implementations (Netscape/SSLref and later MS) never bothered 
implementing it, and since it wasn't in there from the start noone else has 
been able to get it in.  In contrast ssh has has compression built in from the
start, as a result of which every single other implementation also has it, and
everyone uses it.

I think this supports my earlier argument that you need to add something like 
this to a new(-ish) protocol, because it's never going to be retrofitted to 
anything with an installed base (eg MIME).  SSL vs ssh compression (and also
PGP vs S/MIME, which I'd already mentioned) only proves this point.

Peter.

---

From: EKR <[email-masked]>
Date: 03 Aug 1999 13:09:02 -0700

> start, as a result of which every single other implementation also has it, and
My reading of the TLS/SSL compression situation is rather
different. 

First, neither SSL nor TLS in fact defines compression.
Rather, they define a slot in which compression could be 
fitted if one were to define it. No specific algorithm is
defined. 

My interpretation of the history is that compression support
foundered on intellectual property issues. I.e. there was no
algorithm which everyone could agree was unencumbered. Since
there was a desire to get the spec out quickly and the issue
was sticky, it was punted. I definitely remember several
meetings of the IPSEC working group where the IP situation
was discussed and it was distinctly murky.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/