Subject: [lemonade] Notes on Compression

From: Randall Gellens <[email-masked]>
Date: Mon, 10 Jul 2006 14:25:48 -0700

From talking to our client people:

- potential reasons for disabling compression: server bugs, general 
robustness (but clients will likely handle this by closing and 
re-opening the connection anyway, so no need to disable compression 
once it has been enabled)

- no good reason to negotiate down & up separately: do whatever is 
simpler for the protocol

- potential memory requirements? Server compresses something that 
exceeds client ability (size of dictionary): is this handled by 
compression mechanism?

- ordering: do TLS first (of course), then compression, then SASL. 
Note that if TLS compression is used, then SASL authentication will 
be compressed anyway, so may as well compress SASL exchange when 
using IMAP/Submission compression

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Adding manpower to a late software project makes it later.
                -- Fred Brooks in _The Mythical Man Month_

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Jul 2006 23:04:15 +0100

> exceeds client ability (size of dictionary): is this handled by 
Deflate wouldn't suffer this problem - its memory requirements are 
pretty well constant no matter what the encoded stream.

> using IMAP/Submission compression
This is fine, until you consider the case where SASL negotiates a 
security layer.

Two ways of handling this:

1) SASL refuses to negotiate a security layer if compression is 
already in effect. Compression negotiated after a security layer is 
okay.

2) SASL negotiates a security layer anyway, and inserts the layer 
under the existing compression layer.

My implementation of Arnt's draft doesn't do security layers in SASL 
at all, but I would lean toward (2) - I don't think it's as 
complicated as it sounds. (I may revise that opinion, though).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Jul 2006 22:29:13 +0100

On Mon, 10 Jul 2006, Randall Gellens wrote:
>
> - ordering: do TLS first (of course), then compression, then SASL. Note that
> if TLS compression is used, then SASL authentication will be compressed
> anyway, so may as well compress SASL exchange when using IMAP/Submission
> compression

Does the profile exclude SASL encryption layers? If not, the order of TLS
and SASL depends on the SASL mechanism.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHETLAND ISLES: SOUTHEAST 5 OR 6 VEERING WEST OR SOUTHWEST 4 OR 5,
OCCASIONALLY 6 LATER ON TUESDAY. RAIN, THEN SHOWERS ON TUESDAY. MODERATE OR
GOOD, OCCASIONALLY POOR AT FIRST. MODERATE OR ROUGH ON EXPOSED WATERS.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 11 Jul 2006 03:49:01 -0700

> and SASL depends on the SASL mechanism.

I believe Randall's ordering is the order you should turn them one.
I.e., First do STARTTLS, then negotatiate TLS compression, then
AUTHENTICATE.  In terms of the processing of the data stream, the stacking
will still be
	IMAP protocol stream ->
	SASL security layer ->
	TLS w/compression ->
	TCP stream

Yes, that means that you really shouldn't try to use TLS compression
with a SASL security layer that does confidentiality.  Trying to
insert SASL layers into the middle of the TLS processing is a
non-starter...

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Jul 2006 18:50:26 +0100

Dave Cridland wrote:

> already in effect. Compression negotiated after a security layer is okay.
>

I am also leaning toward 2).