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

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 5 Oct 2004 22:37:57 -0700

Lyndon,

>> 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.<<

I hope not... Lemonade is about "enhancing and profiling IMAP and internet e-mail email protocols" (see charter lemonade-charter.txt - Last Modified: 2004-09-17). I assume that it may depend on what we understand by enhancing and profiling... I would argue that it is very much the concern of Lemonade. If IMAP was considering the mobile use cases, why would we need Lemonade? So isn't it explicitly appropriate to consider the use cases met in mobile deployment that IMAP can't handle (or handle poorly, or did not consider, ...) and trying to find a solution?

And, no ,webmail services do not cut it... As demonstrated by the successes of different mobile e-mail offerings - users demand a better experience and enterprises / service providers see business incentives in such services. However, I am trying to understand if some are suggesting that because we do not like that a particular issue that is met in mobile environment and that can't be directly handled by IMAP as it is today, we should not strive to appropriately extend IMAP to address it. If it was the case, I would argue that Lemonade would not have delivered on its objectives for mobile. In any case, if Lemonade can't address such issues (and there are other ways than webmail to do so like for example P-IMAP, WebDAV, etc...), then we may as well just forget about Lemonade's wide adoption or even its relevance for mobile e-mail/environments. 

I think that I have answered your other requests for clarifications in answers to previous e-mails. Let me know if something requires more details.

By now and based on some of the comments and discussions that have taken place so far, I think that we should discuss our objectives for mobile extensions and profiles at the upcoming FTF and clearly decide if we want to address all the real life end to end mobile use cases and issues that prevent mobile e-mail adoption of an open standard approach or if we solely aim at address some subset of issues of interest at the risk of leaving debilitating issues open. In the same vain, I am not sure that we got all our use cases right for mobile. This may also be worth re-visiting at the FTF. 

Looking forward to a good discussion in Vancouver.

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: Lyndon Nerenberg [mailto:[email-masked]] 
Sent: Tuesday, October 05, 2004 9:34 PM
To: Stephane H. Maes; [email-masked]
Subject: RE: [lemonade] Call the Question - Compression: TLS or Application-layer

> 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

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

---

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

--On 2004-10-5 10:37 PM -0700 "Stephane H. Maes" 
<[email-masked]> wrote:

> I think that I have answered your other requests for clarifications
> in answers to previous e-mails. Let me know if something requires
> more details.

Well I've read through the whole discussion a couple of times now, and 
I still can't see a non-hypothetical reason why we would need to add 
compression and encryption to IMAP.

>From an engineering standpoint, adding these to the application 
protocol -- when both are already provided for in the protocol -- makes 
no sense at all. You're making the argument that a client and a server, 
each of which chooses to *not* implement STARTTLS (as is *mandated* by 
RFC3501) are going to implement an optional extension.

Some specific questions I have about this are:

1) Why would a vendor, who can't expend the effort to implement 
something *required* by the standard, implement something that isn't? 
Especially when by not implementing STARTTLS they are seriously 
restricting their customer base?

2) Why would a vendor who *does* properly implement the standard want 
to expend developer resources to code up and support a completely 
redundant way of doing what STARTTLS was designed to do (and already 
does)?

3) What would this extension provide that STARTTLS does not? I want to 
see a specific, real world example. You're going to be hard pressed to 
convince anyone of the need for this unless you can show a 
non-hypothetical case where STARTTLS does not work, and can not be made 
to work.

--lyndon