Subject: RE: [lemonade] Compression: TLS or Application-layer

From: Eric Burger <[email-masked]>
Date: Sat, 2 Oct 2004 21:57:39 -0400

When would you ever have a nat/fw issue with TLS?  IPSec, yes, but TLS, no.

-----Original Message-----
From: Stephane Maes [mailto:[email-masked]]
Sent: Friday, October 01, 2004 4:28 PM
To: [email-masked]
Subject: Re: [lemonade] Compression: TLS or Application-layer

Sorry my laptop is down and I am on the road. It will take me a while to
catch up and participate to these conversations.

I believe we should be able to provide the option to encrypt the content of
the exchanged e-mail / notification with encryption (as we should be able to
use compression).

This guarantees being able to provide the confidentiality and optimizations
required even when you have a device that does not support TLS or you have
firewall issues. Associated to it.

Why can't it be allowed when selected between client and server? I recommend
that it be the case. P-IMAP showed a way to do it. If we have secure
transport (e.g start TLS) we just have not to use any other compression. But
I think it is key to provide that option. P-IMAP showed that it can be done
rather simply.

I think we should allow that to take place.

Stephane
_____
Stephane H. Maes, PhD,
Director of Architecture - Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM, Y!) or [email-masked] (MSN Messenger)

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Fri Oct 01 12:50:45 2004
Subject: Re: [lemonade] Compression: TLS or Application-layer

> If you insist on "NO TLS!" on wireless devices, then you're forcing
> your customers' email out into the open, where nasties like me can
> listen, and that's going to be painful for your customers. On the
> other hand, if you use TLS, then you can either use the null cipher
> for better battery lifetime, or you can use real crypto.

And don't the vast majority of these devices already support SSL (for
https)? I am far from convinced that the incremental cost of adding TLS
is a show stopper. And don't forget, STARTTLS is now mandatory to
implement in IMAP, so the servers that don't currently support it will
soon (or will die out due to market pressure).

I am very strongly opposed to adding compression to IMAP itself. TLS
already provides the infrastructure.

--lyndon

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

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

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

---

From: [email-masked]
Date: Tue, 28 Sep 2004 05:44:27 -0700 (PDT)

> I'm glad you brought this up Eric.  I think this is needed for low
> bandwidth terminals.  Computational power of terminals is growing faster
> than network bandwidth at the current time, so I feel this is a key
> technology.

> I think TLS compression is fine, but for consumer level systems which
> will not be enabling IMAPS (simply because they don't know what it is) I
> think we will need application level compression (like P-IMAPs GZIP).

Ignorance is never an excuse. I also fail to see why someone would be ignorant
of one mechanism but aware of another.

> I agree with Arnt that stream compression is better than individual
> message compression, but we may be able to define both.

Just because we can do something doesn't mean that we should. Less is almost
always more, and unless there's a compelling technical advantage to performing
application layer compression (which is why DATA is important), we have no
business defining it.

				Ned

---

From: [email-masked]
Date: Tue, 28 Sep 2004 11:44:56 -0700 (PDT)

> From an operator's perspective, any feature which reduces bandwidth
> performance is a good thing.  So they would want compression at any
> level.
> However, TLS connections over GPRS networks tend to be expensive to
> setup and difficult to maintain (at least today).

Due, no doubt, to the use of public keys, which as Arnt already pointed
out aren't needed to get compression.

> Another consideration is battery drain.  TLS connections tend to be a
> big load on the battery because of the computational power required to
> decrypt + decompress the stream.  App level compression would improve
> battery life, but would still require more power than no compression at
> all.

Again, you don't need to do crypto to do compression. And since crypto is
highly desirable independent of the compression issue, if this is a valid
concern you need to take it up in the context of the available privacy
mechanisms in TLS to see what can be done to ameliorate it.

> In order to improve the acceptance of email client applications on
> mobile terminals we need to make it as user friendly to the common
> consumer (90% of the market) as possible.  While enterprises are happy
> with TLS compression (or IPSec, MOBIKE, VPN services), allot of
> operators today don't offer IMAP/S access to the ISP email server or
> require a business/enterprise level contract (not to mention Hotmail,
> Yahoo mail, etc.)

Even if this is true (and the number of ISPs I deal with on a regular basis who
insist on TLS support all over the place suggests it is not), I again fail to
see what is magically different about adding application level compression that
is going to make it deploy more quickly. Remember, implementations are already
required to support TLS in IMAP4. AFAIK we barely even have a proposal for
application level compression on the table right now, let alone a finished
standard. And I'm not opimistic that an implementation requirement for all
IMAP4 servers to support application level compression would ever see the light
of day given that other alternatives exist.

> If we can add an extension to the server at the application layer the
> user/operator doesn't have to be aware that it exists at all.  The
> capability is negotiated by the client and server, not configured by the
> user.

The same can be said for compression-only STARTTLS.

> Another problem is the idea of using IMAP server to client notifications
> or IMAP-to-MMS mapping.  In these instances a TLS connection is not
> possible and we may want to add compression technology for transporting
> email messages over MMS networks or OOB OTA email delivery.

> To summarize, I understand you objection and agree if we were designing
> for desktop systems, but Lemonade needs to consider both enterprise and
> consumer based mobile systems where certain technologies are either
> unavailable or unwieldy, requiring us to look at alternative methods to
> deliver the same benefits.  If we can come up with something that does
> not require compression in order to increase bandwidth utilization, I'm
> all for it.

I don't know what it means to have compression without compression. And absent
a compelling technical reason for an application layer compression scheme I am
absolutely apposed since I see it as an unnecessary duplication of effort.

> In the end we need to make mobile email as painless as possible, and
> forcing TLS to compress email will make mobile email clients more
> unwieldy than they already are.

Thus far you have provided no technical reason why this is the case.

				Ned

---

From: [email-masked]
Date: Wed, 29 Sep 2004 07:13:16 -0700 (PDT)

> <chair-hat-off>

> Is gzip less expensive than TLS with null cipher?.

This question is impossible to answer since you haven't stated what other
TLS options are being used. Is integrity protection also in force? Has
a compression layer been negotiated? If so, what is it?

Perhaps you meant to ask which is less expensive: TLS with a null cipher, null
integrity, and deflate compression, or an application-level gzip compression.
If so, then I would expect the costs to be dominated by deflate compression,
which underlies both of these approaches; the blocking overhead of TLS is
almost certainly negligable.

> TLS works on the stream
> (e.g., 8KB or pick your favorite size) at a time, not on the entire message
> (including data).

Both TLS and application layer compression have to have a means of "pushing"
the data out so the dialogue can turn around. This typically translates into
quite a few compression blocks smaller than the maximum.

> This could very well result in fewer instructions,
> meaning less battery drain.  That said, that is why I was wondering about
> the compression performance of TLS vs. gzip.

Compression, like everything else in TLS, is negotiable. If the compression
scheme is negotiated to be deflate, I would expect it to be about the same. If
some other compression scheme got negotiated it might end up being more or less
costly depending.

I believe two compression schemes have been specified for TLS so far, and more
are probablyh on the way. We would probably have to specify a mandatory to
implement scheme.

> I also have serious protocol issues with application-layer compression.
> Today we might like gzip.  Tomorrow we might like ZIP (ignoring IPR
> issues...).  The day after we might want FOOBAR.  After that, BARFOO takes
> hold.  Service provider Z wants to use their proprietary compression
> program.  That means the protocol needs to support application-layer
> compression method negotiation.  TLS, SIGCOMP, et al. have solved this
> already.

Well, we could always define a negotiation mechanism of our own. Or have
multiple separate extensions. But this gets complicated fairly quickly, not to
mention the fact that it could easily end up creating additional turnarounds in
the dialogue and as a result increasing latency.

				Ned