Subject: [lemonade] Question about DEFLATE support in TLS

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Jan 2007 14:34:50 -0800

I'm trying to get a better understanding of what TLS stacks support  
DEFLATE and which ones don't. I scanned the archives since June 2005  
but did not find discussion on this (I easily could have missed it so  
point me the right direction).

Can people point me to previous emails on this?

What TLS stacks don't support compression?

Do any TLS stack support an API to set the compression level?

Thanks, Cullen

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 25 Jan 2007 23:55:07 +0000

You may have more joy asking the TLS people, but some answers:

> What TLS stacks don't support compression?
Symbian's doesn't appear to. I've not tested whatever comes with 
Windows, let alone Windows Mobile. Perhaps a better question to ask 
is what TLS stacks *do* support compression, to which the only 
conclusive response I've ever seen is OpenSSL 0.9.8.

> Do any TLS stack support an API to set the compression level?

I haven't seen such an API for OpenSSL 0.9.8, but most of its 
compression API is undocumented as far as I could see.

libgnutls doesn't appear to either, but equally, its documentation 
suggests it doesn't support compression, at least in places.

Neither allow the compression to be flushed without flushing the 
data, which harms compression or network usage, depending on which 
you prefer preserving.

In summary, I've yet to see a device smaller than a laptop that 
supports TLS compression (including the Nokia 770 and N800), and even 
"proper" computers don't have much of an API.

I'm sure it'll happen, but right now the state of TLS compression is 
pretty poor as far as I can tell.

The trouble is, it's obvious that compression is such low-hanging 
fruit it's one of the first things mobile email developers want to do 
- it's an easy, unintrusive, win. And the existing platforms just 
don't seem to do it.

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: Cullen Jennings <[email-masked]>
Date: Thu, 25 Jan 2007 19:29:17 -0800

Thanks for the replies - I'm still tryng to get my head around all of  
this. I get the feeling from Ted lots of it has been discussed before  
so thanks for taking the time to get me up to speed on the state of  
things.

> You may have more joy asking the TLS people, but some answers:

I asked one of the TLS crowd too

> Symbian's doesn't appear to.

I was staring at my symbian doc and agree the MSecureSocket::SetOpt  
stuff is totally implementation dependent and pretty much  
undocumented. I do note that do have the deflate library on the  
devices and I seem to recall the rumor was the Symbain used the RSA  
stack (which does support compression), and I notice they have a  
particularly juice looking error code of RWTLS::EDecompressionFailure.

> I've not tested whatever comes with Windows, let alone Windows  
> Mobile. Perhaps a better question to ask is what TLS stacks *do*  
> support compression, to which the only conclusive response I've  
> ever seen is OpenSSL 0.9.8.

Well, just working on memory and I may have this wrong: oppenssl,  
gnutls, RSA, certicom.

I'm mostly familiar with the openssl and RSA stuff as I have worked  
on projects using those that across things ranging from high end  
servers to wireless phones.

> data, which harms compression or network usage, depending on which  

I totally agree that most the TLS API I have seen are somewhere  
between bad and worse than that. Now it does not surprise me that no  
one has requested that the TLS API includes a function call to flush  
the DEFLATE or set the compression level - I'll resist from  
suggesting why for now - however - I suspect that it would be pretty  
trivial to implement as they just pass the call on down to the  
DEFLATE library.

> supports TLS compression (including the Nokia 770 and N800), and  
> even "proper" computers don't have much of an API.

I don't have one of those but I'm somewhat shocked to learn they  
won't run openssl.

>
> I'm sure it'll happen, but right now the state of TLS compression  
> is pretty poor as far as I can tell.
>
> fruit it's one of the first things mobile email developers want to  
> do - it's an easy, unintrusive, win. And the existing platforms  
> just don't seem to do it.

Did anyone ask their favorite TLS stack vendor(s) if they could add  
this API? I've had surprisingly good luck with that before.

---

From: "Ben Last" <[email-masked]>
Date: Fri, 26 Jan 2007 08:51:12 -0000

>From: Dave Cridland [mailto:[email-masked]] 
That's correct, in that TTLSCompressionMethod is defined as having one value (ENullCompression) in the 9.1 source tree.  However, a zlib implementation is supplied, so it's possible to stack deflate compression on top of TLS.  You have to do a fair amount of buffer-management to make it work, though.

>The trouble is, it's obvious that compression is such low-hanging fruit it's
>one of the first things mobile email developers want to do - it's an easy, unintrusive,
>win. And the existing platforms just don't seem to do it.

Absolutely.  That's one thing that HTTP as a transport does have in its favour (though there are of course many things to be said against it): it includes well-defined compression as part of the protocol.

Regards
Ben

R&D Manager
EMCC Software Ltd

---

From: Dave Cridland <[email-masked]>
Date: Fri, 26 Jan 2007 09:58:26 +0000

> servers to wireless phones.
For OpenSSL, it's only OpenSSL 0.9.8 and above. 0.9.7 has serious 
deployment, still. (FWIW, it's possible for third-parties to glue TLS 
deflate into OpenSSL 0.9.7, if you jump through some serious hoops, 
as I understand things.)

My bet is that RSA and Certicom's stacks both only support TLS 
compression in later, less well deployed, versions.

>  Now it does not surprise me that no  one has requested that the 
> TLS API includes a function call to flush  the DEFLATE or set the 
> compression level - I'll resist from  suggesting why for now - 
> however - I suspect that it would be pretty  trivial to implement 
> as they just pass the call on down to the  DEFLATE library.
> 
> 
Yes, changing TLS library APIs would be good, but...

> I don't have one of those but I'm somewhat shocked to learn they  
They do. OpenSSL 0.9.7, though...

>  this API? I've had surprisingly good luck with that before.

That's only a tenth of the problem. The real challenge would be then 
getting that API onto the kinds of platforms that much of Lemonade is 
directed toward. Mobile phones, currently, generally do not have 
upgradable firmware, and even if they did, the chances of a 
third-party developer convincing their potential customer to upgrade 
are slim to none at all. And as Ben Last has confirmed, there isn't 
any firmware that would do the trick on at least one major mobile 
handset platform.

The 770 and N800 *do* allow me to upgrade to OpenSSL 0.9.8 seamlessly 
as a third-party developer in principle, but that would require me to 
also upgrade every application which uses OpenSSL 0.9.7, thanks to 
the API change, which includes closed source applications and would 
leave the user with an essentially unsupported OS anyway.

So, I'm left with a custom TLS compression method, or I can support 
COMPRESS=DEFLATE, which is far easier to write, and gets me 
potentially better compression, for the cost of one round-trip at 
session startup time. It's not a hard choice.

Dave.