Subject: Re: [lemonade] Compress result code

From: Philip Guenhter <[email-masked]>
Date: Tue, 11 Jul 2006 16:47:49 -0700

On Wed, 12 Jul 2006, Dave Cridland wrote:
...
> My client has, unfortunately, no idea at all if the TLS implementation has
> negotiated compression. It's a product of the API. So where TLS is
> compressing, I want COMPRESS to say NO. If it said BAD, it'd raise a dialog
> box telling the user I screwed up.

While a server _could_ refuse to support COMPRESS if TLS-level compression
has been negotiated, I don't think it conceptually needs to be banned.  It
certainly isn't a direct result of the model, as they are not a the same
layer.  Indeed, if there's a SASL layer (perhaps integrity), then the SASL
layer would be between COMPRESS's compression and TLS (and its
compression).

btw, is there any reason to believe the server's TLS library is more
likely to support determination of whether compression has been
negotiated?

Philip Guenther

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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 12 Jul 2006 09:01:13 +0100

> layer would be between COMPRESS's compression and TLS (and its
Indeed. It doesn't hurt interop to have both TLS and COMPRESS doing 
compression, it's just silly. Silly is a "SHOULD respond with NO" 
situation. If the client is trying to have two COMPRESS compression 
layers, this is broken. Broken is a "MUST respond with BAD" situation.

What you probably want to do, in an ideal world, is renegotiate TLS 
compression off when you receive a "silly" COMPRESS command and 
respond OK - this is because you can control the compression 
algorithm much better through, say, the zlib API, and achieve much 
better compression.

> likely to support determination of whether compression has been
My particular instance is where my client only has access to the 
standard Python library, in which case it has the ability to start 
TLS, and not even access the certificates. The specific openssl API I 
use where available (PyOpenSSL) has a much better API, but that's 
still lacking compression information. I'm not clear if Symbian, for 
instance, has the API calls to handle this either.

For servers, the prevelant implementation, OpenSSL, only supports 
compression from it's 0.9.8 stream, which in turn has a distinct API 
from 0.9.7, forcing explicit support, and has the API relevant to 
discovering if it has negotiated compression or not.

It is possible that a server may not have the ability to know if TLS 
compression is happening, of course, but I'd say it's a less likely 
situation than in clients, and will probably remain so.

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