Subject: Re: Huffman coding?

From: "Jack De Winter" <[email-masked]>
Date: Wed, 13 May 1998 11:06:49 -0400

At 11:54 AM 5/12/98 +0200, Harald Alvestrand wrote:
>At 10:44 11.05.98 -0400, Jack De Winter wrote:
>>Just as a side note, I am preparing a document on AHUFFMAN-CRAM-MD5,
>>and would appreciate anyone who would like to look over it with me
>>and give it a good first pass.  It supports Adaptive Huffman encoding
>>with a CRAM-MD5 authenticator.
>
>Interesting....how did you end up with Huffman, and not zlib, deflate,
>lz77 or one of the other compression algorithms?
>It's been a long time since I've seen Huffman seriously mentioned....

well, huffman is considered a "base" type in most computing circles, and
I thought it would be a good place to start, and then to progress on to
the other types.  This is kind of like CRAM-MD5 for authentication.
CRAM-MD5 is simple and easy to implement.  

we have plans to put out docs for the others as well, just wanted
to gauge if using SASL was a generally accepted good method for
compression first, or if we need to go to a different access mechanism.
the one downfall of compression under SASL is the need for authentication,
unless we come up with a "NULL" authentication type.

regards,
Jack

-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 May 1998 08:48:32 +0200

>CRAM-MD5 is simple and easy to implement.

I don't think you have seriously thought about the deployment issue.
If we have 15 different compression algorithms being defined through
SASL schemes, and 15 implementations choose 4 at random, the chances
of any two of these parties being able to communicate in compressed mode
become microscopic.

There's also a combinatorial explosion with authentication schemes;
do you really, really want to do KERBEROS-HUFFMAN, KERBEROS-ZLIB,
GSSAPI-HUFFMANN, GSSAPI-ZLIB,  SKEY-HUFFMAN, SKEY-ZLIB et cetera ad
nauseam ad infinitum?

>unless we come up with a "NULL" authentication type.
You already have a "null" authentication, it's called "anonymous".
But I think this approach has serious problems. I'd rather see if you
could make it an orthogonal attribute of the connection.
And remember - when doing encryption, compression must be applied
*before* encryption.

                    Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 14 May 1998 12:53:26 -0400

>GSSAPI-HUFFMANN, GSSAPI-ZLIB,  SKEY-HUFFMAN, SKEY-ZLIB et cetera ad

Very important point, and one that I have not overlooked, but was hoping
to get input from the community on.

Right now, it looks like SASL is being adopted throughout the IETF community
in the various specs (ACAP, SMTP, POP3, IMAP to name a few).  From what
John Meyers mentioned one time, that road of getting authentication
(and compression) to be distributed in such a fashion has been a long
and painful road.

Compression is something that a lot of people are asking for.  If we
have to go through the same thing again, I fear it would never get done.
As such, I asked John about compression one time, and he thought it was
a good idea.

>And remember - when doing encryption, compression must be applied

You know... I had totally missed that one.

Personally, I would prefer to see compression stay within SASL's scope.
A good way to do this might be to extend SASL to allow for an optional
compression type.  A possibility might be:

A01 AUTHENTICATE-COMP <auth-mechanism> <comp-mechanism> <auth-start-data>

I would prefer to see "AUTHENTICATE" by itself, but then there would be
no way of knowing that the second parameter is a compression mechanism
versus the authentication mechanism's start data.

Pros
1) Uses deployed architecture, with minor changes to the authentication
   invocation mechanism and capabilities mechanism (if supported).
2) The SASL mechanism handler would be able to enforce Harald's
   "rule" that compression should be done before encryption.
3) Would use existing deployment to deliver compression to the protocols
   that support it with little change.

Cons
???

Well, seeing as this has got the ball rolling, could people voice
their opinions regarding compression under SASL, pros and cons, and
whether or not they believe that compression types should be placed
under SASL (along with reasons why and why not)?

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Thu, 14 May 1998 11:32:04 -0700 (PDT)

> under SASL (along with reasons why and why not)?

In general, I think a compression layer should be done in combination
with a security layer (integrity/privacy protection).  Adding a new layer
is fairly expensive and making multiple layers above the TCP level work
well is hard.  This follows the "avoid unnecessary layers" design goal.

I'll point out that you may be better off using TLS for compression since
the feature is already built in and the TLS layer is more popular than the
SASL security layer (SASL is more popular for client authentication than
TLS).

If you do compression under SASL, pick only one good algorithm. 
Compression has diminishing returns, so if you start with a good-enough
algorithm, then it's not worth suffering the interoperability problems
necessary to upgrade.  I recommend zlib-deflate because it's good-enough,
already documented in RFC 1950/1951 and it's patent-free.

Security layers are currently negotiated by asking for "integrity" or
"privacy" protection.  Add one more bit to negotiate "zlib-deflate"
compression.  This is a backwards compatible change to the KERBEROS_V4, 
GSSAPI and SCRAM-MD5 mechanisms.  Mechanisms without a security layer
will either have to be revised to add one, or left alone.

Since SCRAM-MD5 is backwards compatible with CRAM-MD5 and supports a
security layer, I'd say that doing just CRAM-MD5 plus compression would be
a waste of time.

		- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 May 1998 10:04:06 +0200

>   "rule" that compression should be done before encryption.

It's not my rule, just an observation that compression after encryption
is 100% useless - an encrypted bitstream is, almost by definition,
indistinguishable in statistical properties from random noise, and
random noise does not compress very well.

Count me as one of those *not* happy with defining compression as
a part of the SASL layer; it's the kitchen sink/hammer analogy again:
burdening a layer with things that do not fit there damages that layer.

(If you want to change the scope of SASL, I think it makes much more
sense to define TLS as a SASL mechanism; the special treatment it
gets now may make sense at a microscopic level, but at the 10.000 foot
level it seems sillier every time I look at it.)

                       Harald

Harald Tveit Alvestrand
IETF Area Director, Operations and Management
NOTE: No longer Area Director for Applications.

---

From: "Jack De Winter" <[email-masked]>
Date: Fri, 15 May 1998 10:29:11 -0400

>level it seems sillier every time I look at it.)

Well, I do remember John trying to do this and getting tonnes of
problems, mainly stemming from the double framing that would go
on.  

I had a look over TLS specs the past couple of days, and I seem to
have made the following observations:

1) Compression seems to be a sideline.  From page 29 of the TLS main
draft, it says that "a client and server will always be able to agree
on a compression method".  My problem with this is that it does not allow
me to set a policy of "anything from [a.b.c.d] must use on of the following
compression methods.
	1a) Because of this, it does not seem to have any way to indicate
		that compression negotiation failed.

2) Unless I am severely misreading this, there is no way to specify
   NULL/NULL/NULL for the connection.  That is no key exchange, no
   cipher and no hash.  For the anonymous example, this is a serious
   impediment.  This means that using TLS between two SMTP servers,
   where those servers did not "know" each other would prevent the use
   of TLS, and hence, any compression that may have been gained is lost.
   2a) There are several places in the TLS docs that state that
       NULL/NULL/NULL is a starting state and is not permitted for the
       connection, as it does not add any extra security.

Because of these "facts" (more like "because of my understanding of the
facts presented in the TLS draft"), I would say that mandatory compression
is not well suited to TLS due to the above points.

As such, I would still like to see extra comments about compression using
SASL, be it combining it with existing types or using an extra parameter.

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Mon, 18 May 1998 12:14:46 -0800 (PST)

> burdening a layer with things that do not fit there damages that layer.

I'm of the opinion that there should be *at most* one layer between TCP
and an application protocol.  I prefer putting integrity protection,
encryption and compression in the same layer since it saves framing
overhead and implementation complexity which would otherwise be necessary.

> level it seems sillier every time I look at it.)

TLS and SASL have different framing mechanisms for their security layers.
So you can't combine them without breaking one or the other security
layer.

Personally, I think it's convenient they're separate given current usage. 
SSL/TLS is normally used for server authentication and privacy, while SASL
is normally used for client authentication.  So it often makes sense to
use both at the same time, which would not be possible if they were
combined. 

Now you wouldn't want to use TLS and SASL's security layer at the same
time, because that's an unnecessary (and redundant) layer.

Finally, I think a compression-only layer is counter-productive.  Let's
use the desire for compression as a hook to get integrity protection (at
least) deployed.

		- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 May 1998 23:06:24 +0200

>overhead and implementation complexity which would otherwise be necessary.
This reminds me of the "application layer framing" approach that I've
seen bandied about around MMUSIC/AVT. It's a good argument.
But in that case, we may need to turn SASL into Simple Anything Session Layer,
with slots for authentication, encryption, integrity protection and
"we haven't thought of it yet".
Because combinatorial explosion is still a Bad Thing for deployment.

>So you can't combine them without breaking one or the other security

SASL as I read it is a way to negotiate into a security layer.
>From my 10.000 foot level, I don't see the great difference between
the exchanges

-> STARTTLS          -> AUTHENTICATE TLS
<- OK			<- OK
...first byte of TLS negotiation starts here in both cases.....

>use both at the same time, which would not be possible if they were

..............actually, why not?
the blocking factor I can see is the text in RFC 2222 section 5.3,
and we change protocols, don't we?

The requirement would be that there at any time be only one of:
- client authentication identity
- client authorization identity
- server authentication identity
- server authorization identity (if there is such a thing)
- protection mechanism
- compression mechanism
- integrity mechanism
and some renegotiations of one should nullify some others.

But I do NOT think adding compression as a property of a SASL
mechanism is going to cut it. Unfortunately.

                        Harald A

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 19 May 1998 11:48:29 -0400

>use the desire for compression as a hook to get integrity protection (at

Hrm... how about the case where you would like to provide compresses
SMTP access?  Now I know that anonymous logins are possible, but unless
we frame the compression within something like GSSAPI or SCRAM, we would
have to provide <type>-ANON and <type>-CRAM-MD5 as Harald mentioned
earlier.

However, as Chris has pointed out to me in private, there are probably
not going to be that many compression types, so this may not be that
bad.

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Tue, 19 May 1998 14:25:00 -0700 (PDT)

> Because combinatorial explosion is still a Bad Thing for deployment.

I oppose any fundamental changes to the SASL base spec, other than removal
of rarely used features/mechanisms.  We're having a *very* hard time
deploying security and the last thing we need to do is mess with something
that's just starting to work. 

> ...first byte of TLS negotiation starts here in both cases.....

SASL's primary use today is to permit use of a non-cleartext client
authentication mechanisms.  The security layer is not used a lot yet.

TLS's primary use today is to authenticate the server and provide a
privacy layer.  Client authentication is rarely used despite being
widely deployed (in the form of SSL client certificate support).

The negotiation and framing they use is completely different.  The SASL
negotiation occurs within the app protocol, while the TLS negotiation
occurs at a lower level invisible to the app protocol.  The SASL framing
uses just simple counted blocks (with a negotiated max size), while the
TLS framing has many complex rules.

They can't be merged into a single layer without fundamental changes to
one or both.  And their primary design goals were sufficiently different
that I don't see any harm from having both around.

> and we change protocols, don't we?

I am strongly opposed to any changes to SASL which would stall the
progression along the standards track.  We need to get security deployed
yesterday, not next year.  It is way too late to change the fundamental
framing mechanisms.

> mechanism is going to cut it. Unfortunately.

How about a new standards track spec which amends SASL in a
backwards-compatible way so that any SASL mechanism with a security layer
can also negotiate compression? 

Note that this is *not* important enough in my book to merit a
non-backwards-compatible change to SASL.  Compression is a nice way to use
spare CPU cycles to save network bandwidth, but it's far from a
requirement. 

		- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 May 1998 13:58:10 +0200

For those mechanisms that have a "function bitmap", it's fairly trivial
to extend those specs with another bit for the "compression" function.

But the bitmap is part of the mechanism, not of SASL.

We could write up a new document entitled "how to write a SASL mechanism",
and recommend that all mechanisms use the same bits in a common way.
We could even make it a requirement on new SASL mechanisms, and claim that
those that do not have it as "implicitly zero".

But I don't feel good about it. Not at all.

               Harald A

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 20 May 1998 10:55:31 -0400

At 02:25 PM 5/19/98 -0700, Chris Newman wrote:
>...

On part of this we agree, and part of this we dont.  Some of our
customers use our software to allow their sales forces to communicate
with the home office on land lines and on cellular lines.  For them,
every second online is costing them money.

regards,
Jack

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 13 May 1998 11:06:49 -0400

regards,
Jack

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 May 1998 08:48:32 +0200

Harald

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 14 May 1998 12:53:26 -0400

Pros

Cons
???

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Thu, 14 May 1998 11:32:04 -0700 (PDT)

- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 May 1998 10:04:06 +0200

Harald

Harald Tveit Alvestrand

---

From: "Jack De Winter" <[email-masked]>
Date: Fri, 15 May 1998 10:29:11 -0400

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Mon, 18 May 1998 12:14:46 -0800 (PST)

- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 May 1998 23:06:24 +0200

the exchanges

                        Harald A

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 19 May 1998 11:48:29 -0400

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Tue, 19 May 1998 14:25:00 -0700 (PDT)

- Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 May 1998 13:58:10 +0200

Harald A

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 20 May 1998 10:55:31 -0400

regards,
Jack