Subject: RE: [lemonade] Call the Question - Compression: TLSorApplication-layer

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 5 Oct 2004 10:30:04 -0700

Mike,

Some comments in-line marked as <SM>...</SM>.

Let me know if it helps.

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 [email-masked]
Sent: Tuesday, October 05, 2004 5:25 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] Call the Question - Compression: TLSorApplication-layer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Stephane H. Maes
> Sent: Tuesday, October 05, 2004 3:26 AM
...
> 
> 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 

This is an orthogonal issue that should not have any bearing on this discussion. This could be a thread by itself, but I do not see how it argues for application level compression.

<SM> If we are recommending STARTTLS to provide compression, then encryption, compression and the firewall issues seem to become entangled. Anyway, even with cipher set to NULL, the firewall will lead to the same type of problems or increase deployment complexities to address. </SM>

> the issues above, it should be possible to use "application
> level encryption" and Application level compression" to 

profile-00 has nothing in it regarding application level encryption. Is there a newer version? 

<SM> Not yet. I am pondering if we should submit an update before Vancouver meeting or after for DC... Actually it does (3.6.  Lemonade Command Extensions) to the extent that it refers to the extension draft that mentions such encryption. Also last paragraph of section on security consideration raises this issue.</SM> 

So you would like application level encryption as well. I believe this is a very serious mistake. Once you go down this route you are now reinventing many security solutions that have already been solved and peer reviewed by the general community.
<SM> I would hope such encryption would rely on well established and reviewed encryption scheme and be optional. It is really the proxy use case that requires that. We may also decide not to specify as part of this work. Still I would recommend that the protocol allows the establishment application level encryption if agreed/required by both end. In the P-IMAP draft we did not specify the encryption scheme, for the same reasons that you indicated I think, but we described a way to have it turned on.</SM>

> 
> 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 you explain in technical detail the problem here. I don't see it. Are you saying there will be a problem similar to WAP Gap or are you saying the WAP Gap will be a problem. The "WAP Gap" was solved by WAP 2.0.

<SM>
I am saying that there may be a problem similar to WAP Gap for some deployment models. 

I claim that a deployment model of interest for operators and enterprises consists of:
- Mobile clients in the mobile network.
- Lemonade proxy server (i.e. a converter between Lemonade and backend e-mail protocol like imap) in operator / SP domain. [Could also be in DMZ]
- Backend end e-mail server in enterprise.

Most mobile e-mail deployment today are based on such type of configurations. I believe that these will be the first types of large deployments that we will see.
</SM> 

Mike

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

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