Subject: Re: Compressed data type for S/MIME

From: Dean Povey <[email-masked]>
Date: Sun, 01 Aug 1999 15:41:25 +1000

My $0.02 to this debate.

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).  This has lead at
least some people to form the opinion that compression doesn't really
belong in a crypto protocol, but at the application layer where the 
information to make these sort of decisions is available.

Now of course the situation in S/MIME is somewhat different to SSL/TLS, as
you can be less concerned about the CPU wastage of compressing stuff that
is already compressed as a client is generally just decoding messages one
at a time (an exception to this is email "VPNs" such as WorldSecure which
convert plaintext mail to S/MIME and vice versa, thus CPU load for such
servers becomes significant). Nevertheless, it seems to me that S/MIME is
much better served by leaving compression out, and putting it into MIME. 
(Encoding-type: application/gzip perhaps?). 

As for Peter's argument about Non-MIME CMS applications I guess I can only
say that if the underlying content that CMS is encapsulating needs
compression, then the underlying content handler should do it.  We could 
make the same argument for any presentation-layer like service that we can 
for compression (e.g. content needs to be 7-bit clean), but this doesn't 
mean that all this encoding should be handled by CMS.

Lastly, the comment was made that it will be difficult to get MIME 
implementations to switch over to using a compressed type.  This has a 
grain of truth, but ask youself which is easier: supporting a compression 
MIME encoding, or supporting S/MIME?  Non-trivial architectural changes 
will always take a while to propagate.

This said, I can't see a real problem with supporting a CompressedData type
(apart from the fact that I don't like it), provided it is optional (i.e.
you have to know that the person at the other end supports it to use it).
While not the best solution it possibly has some value for encapsualting
legacy protocols in CMS blobs.

Cheers.

-- 
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 4 Aug 1999 11:54:49 +1200 (NZST)

EKR <[email-masked]> writes:

>I'm quite aware that there are a number of free implementations of 
>compression and that the authors claim that those implementations are
>enencumbered, 

If any patent did cover zlib, the fact that half the planet uses it and the 
patent holders haven't taken any action would make their case pretty 
difficult in court.

>discussions with holders of the various patents (Hi/Fn comes to mind) seem to
>indicate that they feel otherwise.

... and they'd be very happy to sell you something based on their claims.

Any claim that Hi/Fn may make about coverage of zlib is completely bogus, 
they're either referring to the Waterworth patent which covers what's
generally known as the LZRW1 algorithm (the exact same algorithm was also 
patented by Gibson and Graybill (isn't the US patent system wonderful? :-),
LZRW1 isn't even remotely similar to zlib), or more likely the Whiting 
patent, for which noone's ever really been able to explain how it differs 
from LZSS which was published about a decade earlier.  This is probably why
Stac have never tried to enforce it (they went after MS with Waterworth).

Were any representatives of the data compression community present at these
meetings?  They would have shot down claims like this fairly quickly, these
things have been analysed to death in comp.compression.  Any claims that you 
can get into trouble for using zlib are about as valid as claims that you 
have to pay Hitachi every time you use SHA-1.

Peter.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 04 Aug 1999 09:15:01 -0600

Well said, Ned.

Granted that this isn't the SSL forum, we at Novell have devoting a lot of time 
and attention to optimizing the performance of our SSL implementation

Although most of that effort has been devoted to cleaning up code paths 
in some third-party software and worrying about the public key handshake, 
improvements in the encryption performance for long blocks (large GIF images,
or megabyte file transfers) would certainly be welcome.

At present, it isn't clear to me exactly how much support the CMS spec has 
outside of the S/MIME community, although I understand that it was intended 
to be more general.

What would it take to get SSL/TLS, IPSEC, and some of the other protocols
to adopt CMS, if that is the preferred solution?

If crossing that bridge is too hard, defining a new crypto algorithm that includes 
compression, despite the admitted ugliness and combinatorial problems that
would bring, might still be the preferred answer -- at least for non-CMS protocols.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Ned Freed <[email-masked]> 08/03/99 05:50PM >>>
> > This seems a bit odd, given that a completely unencumbered algorithm and free
> > implementation existed years before the web (let alone SSL) did.  There are
> > problems with ITU and ISO-standarised algorithms (which seem to exist solely
> > to provide patent licensing outlets for vendors, and which in any case tend to
> > have mediocre performance), but Zip/zlib has never had any problems

> enencumbered, however, discussions with holders of the various
> patents (Hi/Fn comes to mind) seem to indicate that they feel
> otherwise.

First of all, while the IETF prefers unemcumbered algorithms, they are not
required. The only requirement is that intellectual property claims be
disclosed when participants in the effort become aware of them.

Second, one of the basic principles underlying patents is that you either
enforce them or lose them. As such, if someone claims to have a patent that
covers Zip/Zlib/deflate, they should have been going after any number of
vendors of the numerous commercial and free software packages that use these
algorithms. The fact that no such action has been taken (it would generate tons
of publicity if it had) is a strong indicator that either no such patent
exists, or if it is does it is no longer enforeable, people's "feelings"
about the matter notwithstanding.

Third, one of the tactics commonly used in this game is to create FUD over
what's patented and what is not. As such, it is quite common to hear second
or third-hand assertions that so and so or such and such has a patent that
covers various things when in fact no such patent exists (and in some cases
no such assertions have been made).

So, if you know of a specific patent that you believe covers deflate, or of a
specific public statement made by someone that they have such a patent, please
step up to the plate and say exactly what it is so we can evaluate it. This is
a technical forum and rumor and innuendo have no place here.

				Ned

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 4 Aug 1999 12:29:57 -0400 (EDT)

> to adopt CMS, if that is the preferred solution?

Bob,

  That wouldn't work.  CMS is about Independent Data Unit Protection,
whereas both IPSEC and TLS are stream protection mechanisms.  (IPSEC
protects individual packets, but relies on a previously established
Security Association to provide the symmetric key for that protection).

Besides, both IPSEC and TLS have their own unique syntax representation
languages, and wouldn't want to use CMS's ASN.1 :-).

Dave

---------------- snip here to avoid rant ----------------------

I've often wondered whether ASN.1 could be used to express the bits on
the wire of an existing protocol such as IPSEC's AH.   To do so, one
would need to define "Fixed-field Encoding Rules" (FER) which would
place only data (not tag or length) octets in the datastream, and a set
of macros to conveniently represent the necessary fields.

For example:

   Int8  ::= INTEGER (0..255)
   Int16 ::= INTEGER (0..65535)
   Int32 ::= INTEGER (0..<4G>)
   
   AuthenticationHeader ::= SEQUENCE {
       nextHeader          Int8,
       payloadLen          Int8,
       reserved            Int16,
       spi                 Int32,
       sequenceNumber      Int32,
       authenticationData  OCTET STRING }

The bits-in-boxes notation used by IPSEC is easy for humans to read and
steeped in tradition, even if not easily machine readable.  But inventing a
unique language for the sole purpose of describing SSL 3.0 strikes me as,
well, goofy.  Wouldn't a protocol-independent description language be
easier on everyone?