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

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 5 Oct 2004 00:26:21 -0700

All,

In our view, it is fine to support STARTTLS for encryption (confidentiality and integrity) as well as compression; but this is not sufficient.

Therefore we do not support a statement that would indicate that Lemonade solely relies on STARTTLS. Instead we recommend that the profile provide the option for client and server to select "application level compression" and "application level encryption". 

We caution against imposing too many assumptions on the network transport that may prevent reuse of the protocol in other environments / situations like mobile access to corporate e-mail in general or over other transport bindings. We are concerned that such kinds of assumptions in the past have plagued widely spread adoption of mobile e-mail by enterprises or deployments by operators. We should try to avoid any unnecessary limitation.

Note that the arguments presented here differ from the discussions that have taken place so far, without prejudging the outcome of these other discussions... But as Lemonade aims at supporting mobile e-mail, among other things, it should take into account the specificity of mobile networks and the realities of mobile deployments / usages; even when it involves aspects not typically met by IETF with conventional internet technologies...

First, it is in our experience that corporate may not open firewall port other than 80 and 443. This is a typical use case of why IMAP over TLS (IMAPS, ...) does not solve all issues even if supported by server behind firewall and by a mobile phone... We have observed numerous such cases of large corporations with IMAP servers (that support STARTTLS) that can't be accessed by clients on GPRS, 3G or CDMA (etc... Take you pick) phones / smart phones even when they also support STARTTLS. And VPN is often not an option (closed platform) or very impractical (considering the constraints of mobile network and devices). Lemonade should not make assumptions on the transport that may prevent its use through firewall.

When a binding / transport different than TLS is used (e.g. HTTP or HTTPS as described in P-IMAP) for example to address the issues above, it should be possible to use "application level encryption" and Application level compression" to achieve appropriate confidentiality and optimization. For example, if the solution relies on HTTPS, it is our experience that mobile clients (even the latest ones) may use (often use) older versions of SSL where application level encryption of the payload is needed. 

Therefore, and based on the simple mechanism described in P-IMAP and lessons learned from real life deployments, we recommend the support of gzip for compression as well as an encryption mechanism as proposed in P-IMAP and letting the server and client turn it on when needed / if needed. The CAPABILITY mechanism easily takes care of most of the issues. Market adoption will later decide if one of the mechanism is superfluous. However, not to provide this mechanism may stifle adoption...

In addition, as a related topic, and in order to allow use case / deployment model where a lemonade proxy is deployed in a service provider / operator domain that differs from corporate mail server, it is critical that application level encryption of the payload be possible. Otherwise, we risk similar security holes similar to the famous "WAP gap" that could doom such deployment models and threaten adoption of the protocol by the mobile industry: service providers want a solution that allows them to host such proxy and some enterprises (at least for small and medium enterprises) want to be able to rely on such hosted services but require end-to-end security.

So we do not agree with imposing network transport assumptions that would hurt adoption and limit deployment options. Especially as we have validate in deployments and it was confirmed in related mailing list discussions that performances and complexity of the two are equivalent and as the CAPABILITY mechanism provides the necessary flexibility for the vendors. 

We do agree with the value of being able to simply rely on STARTTLS when appropriate. However when STARTTLS is not supported or not enough, application level encryption and compression MUST be possible and therefore described in the Lemonade profile.

Thanks

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Monday, October 04, 2004 1:59 PM
To: [email-masked]
Cc: 'Ted Hardie'
Subject: RE: [lemonade] Call the Question - Compression: TLS or Application-layer

Excellent points.

For those that won't read to the bottom: Comments due 12 October.

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Monday, October 04, 2004 2:15 PM
> To: Eric Burger; [email-masked]
> Subject: Re: [lemonade] Call the Quetion - Compression: TLS or 
> Application-layer
> 
> 
> At 1:34 PM -0400 10/4/04, Eric Burger wrote:
> >Given the discussion so far on compression, I would like to call the 
> >question of  how lemonade will  support compression.
> >
> >How is this for a proposal:
> >
> >Lemonade will not specify any proprietary, application level
> compression.
> 
> I am not sure what proprietary means in the above.  Do you mean: 
> "Lemonade will not specify any application-protocol specific 
> compression for IMAP"?

Your language is much better than mine.

> >Lemonade will require, in the profile, TLS support.
> >
> >Lemonade will suggest, in the profile, that if one requires
> compression,
> >that one use TLS with a NULL cipher.
> 
> I assume this would allow someone to use a cipher stronger than null 
> and compression?

Correct.

> >  We should document the points raised
> >on the list of why, namely:
> >* Same computational complexity for, e.g., gzipping data in
> the application
> >versus TLS with NULL cipher in the transport layer.
> >* All IMAP servers are required to support TLS, so server
> (and, for the most
> >part, clients) do not need to change
> 
> Or, possibly, clients who do need to change would have had to anyway?

Is there a way to word this?

> >* The entire IMAP stream, including login, commands, etc.,
> benefit from
> >compression, not just data
> >
> >Unless there are serious objections raised on the list, this
> is the way we
> >will go.
> >
> ><chair-hat-on>
> >If you have objections, raise them now or forever hold your peace. 
> ></chair-hat-on>
> >
> 
> 
> It's difficult for a working group participant to know when "now" has 
> passed when reading a mailing list.  A set period for comments and/or 
> a decision date are easier.  Could I ask you to name a period or an 
> end date for comments?
> 			thanks,
> 				Ted Hardie

Good point.  In time for the Interim on 12 October 2004.

_______________________________________________
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: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Oct 2004 12:09:57 +0200

Could you please confirm that I've understood your position correctly, 
or if not, correct any misconceptions?

1. You're saying that many corporations have decided to let only HTTP 
and HTTPS through their firewalls. You're arguing that for this reason, 
LEMONADE should try to disguise IMAP connections as either HTTP or 
HTTPS.

2. You're saying that many devices cannot support the desired 
compression functionality as part of TLS (because they cannot upgrade 
TLS), but can do so as an IMAP extension. You're arguing that for this 
reason, LEMONADE should include application-level compression as well 
as TLS-level.

3. You're saying that TLS is (often?) deployed such that a part of the 
way between client and server is unprotected, and that an 
application-level approach will not suffer from this weakness, and that 
therefore, an application-level solution is desirable.

Arnt

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 05 Oct 2004 21:33:59 -0700

> First, it is in our experience that corporate may not open firewall
> port other than 80 and 443.

Then their only option is to run a webmail service. IMAP doesn't factor 
into this case, therefore it's not a concern of Lemonade.

> We have observed
> numerous such cases of large corporations with IMAP servers (that
> support STARTTLS) that can't be accessed by clients on GPRS, 3G or
> CDMA (etc... Take you pick) phones / smart phones even when they also
> support STARTTLS.

Why not? What's the failure mode? We need more data before we can 
determine what the actual problem is.

> When a binding / transport different than TLS is used (e.g. HTTP or
> HTTPS as described in P-IMAP) for example to address the issues
> above, it should be possible to use "application level encryption"
> and Application level compression" to achieve appropriate
> confidentiality and optimization. For example, if the solution relies
> on HTTPS, it is our experience that mobile clients (even the latest
> ones) may use (often use) older versions of SSL where application
> level encryption of the payload is needed.

This just seems like a lot of handwaving to me. What I understand you 
to be saying here is that we need to add a new IMAP extension for 
compression and security because old software uses obsolete encryption 
schemes? This makes no sense.

> Therefore, and based on the simple mechanism described in P-IMAP and
> lessons learned from real life deployments, we recommend the support
> of gzip for compression as well as an encryption mechanism as
> proposed in P-IMAP and letting the server and client turn it on when
> needed / if needed. The CAPABILITY mechanism easily takes care of
> most of the issues. Market adoption will later decide if one of the
> mechanism is superfluous. However, not to provide this mechanism may
> stifle adoption...

But every current and future IMAP server and client already have this 
in the form of the STARTTLS command. I haven't yet seen any specific 
argument put forward that shows why STARTTLS cannot work.

> In addition, as a related topic, and in order to allow use case /
> deployment model where a lemonade proxy is deployed in a service
> provider / operator domain that differs from corporate mail server,
> it is critical that application level encryption of the payload be
> possible.

Okay, fine. But until this mythical new protocol is defined it is 
pointless to even speculate about what sort of application-level 
compression or encryption it might need.

The only protocol of interest today is IMAP, and it's IMAP we are 
discussing, and IMAP addresses these issues through STARTTLS.

> We do agree with the value of being able to simply rely on STARTTLS
> when appropriate. However when STARTTLS is not supported or not
> enough, application level encryption and compression MUST be possible
> and therefore described in the Lemonade profile.

Again, support for STARTTLS is MANDATORY; the support has to be there.

Can you please elaborate on what you mean by "when STARTTLS is ... not 
enough."

--lyndon