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

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

Arnt,

Thanks for your questions for clarification. I have answers below in-line between <SM> ... </SM>.

I hope that it clarifies. Let me know otherwise.

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: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Tuesday, October 05, 2004 3:10 AM
To: [email-masked]
Cc: Eric Burger; Stephane H. Maes
Subject: Re: [lemonade] Call the Question - Compression: TLS or Application-layer

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. <SM> Yes that is correct; unfortunately. It takes time to change such guidelines. So to help adoption, we should not prevent variations that can cope with this situation.</SM>

You're arguing that for this reason, 
LEMONADE should try to disguise IMAP connections as either HTTP or 
HTTPS. 

<SM> More or less correct, but it needs some qualifications: I am arguing that Lemonade ****should not prevent*** using other bindings / mechanisms that would work through such firewall. We may not have to try to disguise in the spec but we should not prevent such a solution. In such case, it is important that the lemonade profile optimizations still be useful when using such approaches. Otherwise, I am concerned that adoption of Lemonade for mobile e-mail may suffer.

I believe that OMA will follow our work and produce an end-to-end recommendation for mobile e-mail that may recommend bindings, settings and other aspects on top of the protocol. It is important that it be able to point to Lemonade as core protocol. If main deployment use cases can't be supported, this may be a problem.

BTW, and I hope that this will not also distract the discussion, but we also believe that more efficient transport mechanisms exist and may be considered over mobile networks. We would like to leave open the possibility for Lemonade to be transported on them if desired. Again this requires that Lemonade does not constraint the assumptions on the transport.</SM>

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.

<SM> That is not exactly the trust of my argument to recommend the optional support of application level compression / encryption. Sorry if it distracted. I only intended to observe that in our experience, device manufacturers / client developers may more easily first upgrade protocol plug-ins for e-mail client that reuse the rest of the stack rather than replace the whole stack. So and without claiming to understand all the implications for mobile devices of implementing the different versions of SSL, we see that compressions aspects may not always be available in the immediate future. Device vendors may be able to better comment, however I think it is aligned with the TLS / SSL concerns raised by others earlier. Again, we would like to see Lemonade quickly adoptable instead of being bugged down by such considerations.</SM>

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.

<SM> No, I am not saying that TLS is (often?) deployed such that a part of the 
way between client and server is unprotected. I do not believe that this is true.

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.

It is important that we support these deployment model with end to end confidentiality; i.e. without a stage where the messages may be in clear outside the enterprise domain. This is the problem that plagued WAP (aka the WAP gap). I  used it only as an analogy... An application-level encryption is one way to address this issue and guarantee end -to-end encryption of the messages when needed. 

Encryption and compression are linked discussions if we start considering STARTTLS as an option to perform compression.</SM>

Arnt

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