Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in TLS

From: [email-masked] (Marc VanHeyningen)
Date: Mon, 04 Dec 2000 09:15:46 -0800

> Years ago Eric Young added RLE and ZLIB compression to his SSLeay
> package and I want to use them in OpenSSL.  On some connections I have
> seen dramatic improvements in performance with the use of
> compression.  The specific implementation is for TLS Telnet with X
> Windows Forwarding and TLS FTP.
> 
> Have numbers been assigned?  If so, what are they?
>
> If not, what is the approved method for allocation?  I don't see any
> TLS related registration lists at the IANA site.

I don't know of any official mechanism for it (and apparently nobody
else does either); there has been some cooperation among implementors
on it, obviously.  FWIW, Eric (as you probably know) was using 0xe0
for ZLIB.  Aventail uses LZS with SSL, with an identifier of 0xd0.  What
algorithm do you plan to use?

- Marc

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 4 Dec 2000 12:23:38 EST

> algorithm do you plan to use?

I plan to use ZLIB.  

Do you know what value was used for RLE?

All that needs to be done is for the WG chairs to ask IANA to start to
maintain a list of values for use with the TLS RFC.  Then IANA can
assign numbers as needed.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Dec 2000 09:37:41 -0800

> assign numbers as needed.
Since we only have 256 possible compression algorithm values, I think
it would pay to be a little careful about just letting arbitrary people
assign numbers. 

Obviously, we won't want anywhere near that many standard algorithms,
but I could easily see that many proprietary algorithms.

I propose the following:
1. Algorithms with value >=192 won't be standardized and are for private
   use.
2. Algorithms with values between 64 and 192 may be standardized by
   IANA but require some kind of RFC (informational will do).
3. Algorithms with value <64 are reserved for the TLS working group.

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 4 Dec 2000 12:44:18 EST

> 3. Algorithms with value <64 are reserved for the TLS working group.

In general, numbers need to be assigned before there is an RFC.  Given
how long it takes for RFCs to be issued requiring an RFC before
issuance is unrealistic.  In general, IANA is rather careful about not
issuing out numbers without checking first with the WG chair (if there
is a working group) or the Area Director.  And they (now) require an
Internet-Draft be submitted before the number is issued.  So I think
that middle range can be removed.

I agree that there should be some range allocated for private use. 

Now we have a partial list of algorithms.  If ZLIB is 0x0e and LZS is
0x0d then does that imply that there are 13 other compression
algorithms whose values are already in use?  This is important to
know.  I recently when through a similar exercise with Telnet Options
and sub option values because IANA was not asked to assign values and
it was discovered that many valid values had to be blocked out because
implementors had been using them at random because there was no way to
find out what the official values were and no way to register their
usage.  It would be a shame to have to block off the first thirteen
values simply because we don't know what they are used for or if they
are used for anything at all.

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Dec 2000 09:55:04 -0800

Jeffrey Altman <[email-masked]> writes:
> In general, IANA is rather careful about not
That's fine with me.

> algorithms whose values are already in use?
I don't know, but I rather suspect that Eric just decided to 
leave some room at the bottom :)

I've never heard of any implementation that uses them.

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 4 Dec 2000 12:58:24 EST

> I've never heard of any implementation that uses them.

RLE and ZLIB were both implemented in SSLeay (by EAY) and naturally
they are still supported in OpenSSL.  I have been working on cleaning
up this code to make it useable.  I have found this code to be
absolutely crucial for use in communicating over PPP links since the
encryption nullifies the compression algorithms used by the modems.

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Dec 2000 10:06:47 -0800

> encryption nullifies the compression algorithms used by the modems.
Sorry I wasn't clear. I know that OpenSSL supports RLE and ZLIB.

What I meant was that I've never seen any implementation that used
the algorithm identifiers between 1 and 0xd.

-Ekr

---

---

From: [email-masked] (Marc VanHeyningen)
Date: Tue, 05 Dec 2000 08:58:47 -0800

> > algorithms whose values are already in use?

Er, no.  ZLIB is 0xe0, not 0x0e, and LZS is 0xd0.  Under EricR's proposed
partitioning, that means they're in the "private use" space, which was the
general intent.

> leave some room at the bottom :)

EricY and I both indepdendently chose 0xe0 as the identifier for ZLIB 
(kind of a creepy conincidence.)  I believe his reasoning was that, for
the SSLeay library, the address range e0 through ef seemed the logical
one to use as semi-private space for "e" to be using.

I think we shared the assumptions that:

- If the working group ever standardized algorithms, they would use the
  lower part of the range as "official" and the upper part as "private."
- The WG would not be doing this soon, if ever.

> I've never heard of any implementation that uses them.

I haven't heard of anybody using any compression mechanism under d0
either (except for 0, of course.)

- Marc

-- 
Marc VanHeyningen                 [email-masked]
Internet Security Architect
Aventail                          http://www.aventail.com/

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 5 Dec 2000 12:19:32 EST

Does anyone object to standardizing some of these values?

> partitioning, that means they're in the "private use" space, which was the

Thanks for the correction.
 
> either (except for 0, of course.)

This makes sense.  Does anyone have any objection to standardizing
some values for these compression algorithms?

As libraries mature, the compression algorithms they provide will
become more pervasive and data compression will certainly help in the
low bandwidth environments.

How about

  TLS_COMP_NONE 0
  TLS_COMP_ZLIB 1
  TLS_COMP_RLE  2
  TLS_COMP_LZS  3

and we can go on from there?  I can write up the Internet-Draft if no
one sees a problem with this.

---

---

From: Eric Rescorla <[email-masked]>
Date: 05 Dec 2000 09:23:43 -0800

> partitioning, that means they're in the "private use" space, which was the
One question to ask here is whether support for these algorithms
is sufficiently widespread to merit trying to salvage the IDs.

Marc, is your ZLIB implementation compatible with EAYs? 
Jeff, in your code cleanup are you changing the bits on the 
wire?

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 5 Dec 2000 12:25:01 EST

> Jeff, in your code cleanup are you changing the bits on the 

I am not changing the bits on the wire.  Just some items internal to
OpenSSL.

---

---

From: Eric Rescorla <[email-masked]>
Date: 05 Dec 2000 09:33:59 -0800

> Does anyone object to standardizing some of these values?
Not in theory.

> one sees a problem with this.
The reason that the TLS WG didn't do this originally was because
of intellectual property considerations. I know that Hi/fn has
repeatedly asserted that they have patents on LZS (see RFC 2395).

ISTR that someone claims IP on RLE, but I'm not sure. RFC 2394
claims that ZLIB (called DEFLATE in that draft) is patent-free.

Would you want these drafts to be Informational or Proposed?

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 5 Dec 2000 12:36:59 EST

> Would you want these drafts to be Informational or Proposed?

Proposed Standard would be best.  I would be happy with only
defining a value for ZLIB (deflate).  Deflate is the algorithm used in
GZIP and ZIP/UNZIP.

---

---

From: Eric Rescorla <[email-masked]>
Date: 05 Dec 2000 09:54:12 -0800

> defining a value for ZLIB (deflate).  Deflate is the algorithm used in
I think it's best to go with that, then.

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 5 Dec 2000 13:00:04 EST

> I think it's best to go with that, then.

Ok.  Then I will write up an Internet-Draft for use of ZLIB (DEFLATE)
as a compression algorithm for TLS with an ID value of 0x01.  (unless
there is agreement to preserve the existing values.)

The draft will partition the ID space into two ranges:

  < 192  - reserved for IANA registrations
  >= 192 - private use

---

---

From: [email-masked] (Marc VanHeyningen)
Date: Wed, 06 Dec 2000 10:40:47 -0800

Eric Rescorla awk:
> > ZLIB is 0xe0, not 0x0e, and LZS is 0xd0.  Under EricR's proposed

Never tried it; by the time Eric was doing ZLIB experimentation, we had
abandoned it (it seemed too slow for compressing data streams, though 
Moore's law may have changed that) in favor of licensing LZS from Hi/fn.

We only use LZS when using TLS in the context of SOCKSv5, not for https
or any of the more widely deployed protocols.  Because of that, I don't
see a strong case for preserving the 0xd0 identifier if LZS gets some
kind of registered status.  Eric's ZLIB experiments clearly have enjoy
much wider distribution, so the story may be different there.

- Marc

---