Subject: Re: [lemonade] Re: I-D ACTION:draft-ietf-lemonade-compress-05.txt

From: Ken Murchison <[email-masked]>
Date: Mon, 27 Nov 2006 17:10:22 -0500

Randall Gellens wrote:
> At 11:16 AM +0100 10/5/06, Dave Cridland wrote:
> 
>>  With SASL, the negotiation takes place above the compression layer, 
>> but the security layer (if any) happens below the compression.
> 
> The wording I suggested tries to be careful to only talk about a SASL 
> security layer, not the SASL negotiation.  If we want to make this more 
> explicit, we could add a one-sentence paragraph to this affect before 
> the text.
> 
>>  With TLS, I assume the negotiation happens below the compression 
>> layer, if any, not above.
> 
> Do we want to have text recommending the order that clients issue 
> STARTTLS, AUTHENTICATE, and COMPRESS?  I know we discussed this a while 
> back, with some difference of opinion as to if authentication should be 
> done before or after compression.  If I recall correctly, doing 
> compression before authentication saves bandwidth, but doing it after 
> makes it easier to debug.
> 
> Presumably, we would add new one-sentence paragraph along the lines of:
> 
> "Clients making use of TLS, SASL authentication, and compression SHOULD 
> issue these commands in the following order: first STARTTLS, then 
> AUTHENTICATE, and finally COMPRESS."
> 
> (Or swap COMPRESS and AUTHENTICATE if that is the way we want to go.)

I notice that no such wording was added to -06 and I'm wondering why.

Unless I'm reading -06 incorrectly, if we allow the COMPRESS command 
before STARTTLS, then we compress the TLS records during the TLS 
negotiation, but then once the negotiation is complete we stop 
compressing the whole TLS records and just compress the application data 
in the records.

In order to have some uniformity, I'd suggest that we either state that 
the COMPRESS command MUST NOT be used prior to STARTTLS, or we change 
the ordering in how we process data such that the compression is the 
outermost layer rather than the innermost layer.  My preference is the 
former since its easier to implement IMHO.

Unless there is a *huge* benefit to compressing the SASL exchange, why 
not just enforce the order of the commands as STARTTLS, 
LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces STARTTLS 
before LOGIN/AUTHENTICATE) which would make COMPRESS a 'command-auth' 
rather than a 'command-any' in the ABNF.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 29 Nov 2006 16:15:21 +0100

> I notice that no such wording was added to -06 and I'm wondering why.

Because I messed up. Edited both on my officebox and my laptop, and 
forgot to merge. A very simple operation, really, but I didn't do it. 
Mea culpa. Three documents suffered. You know two of them already, the 
third is NOTIFY, whose -02 revision omits the word 'messages' in a 
critical spot.

But I like your suggestion better than the text I had typed:

> LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already enforces 
> STARTTLS before LOGIN/AUTHENTICATE) which would make COMPRESS a 
> 'command-auth' rather than a 'command-any' in the ABNF.

(I wasn't aware of the mandate in 3501.)

The SASL exchange occurs just one per connection in the common case, so 
personally I don't care about compressing it. O(1) is O(1) is O(1). 
Besides AUTHENTICATE disturbs compression by using base64, so I doubt 
that it would be compressed very much.

Could we do this? Switch to command-auth and done?

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Nov 2006 10:50:38 -0500

> (I wasn't aware of the mandate in 3501.)

Its not *real* explicit, but all 3 are command-nonauth, but only LOGIN 
and AUTHENTICATE move you to authenticated state.  Therefore, STARTTLS 
can not be used after LOGIN/AUTHENTICATE.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Nov 2006 16:33:49 +0000

Arnt Gulbrandsen wrote:

>> Unless there is a *huge* benefit to compressing the SASL exchange, 
>> why not just enforce the order of the commands as STARTTLS, 
> The SASL exchange occurs just one per connection in the common case, 
> so personally I don't care about compressing it. O(1) is O(1) is O(1). 

I am fine with this change.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 29 Nov 2006 20:11:55 +0000

On Wed Nov 29 16:33:49 2006, Alexey Melnikov wrote:
> Arnt Gulbrandsen wrote:
> 
>>> Unless there is a *huge* benefit to compressing the SASL 
>>> exchange, why not just enforce the order of the commands as 
>>> STARTTLS, LOGIN/AUTHENTICATE, COMPRESS (note that 3501 already 
>>> enforces STARTTLS before LOGIN/AUTHENTICATE) which would make 
>>> COMPRESS a 'command-auth' rather than a 'command-any' in the ABNF.
>> 
>> The SASL exchange occurs just one per connection in the common 
>> case, so personally I don't care about compressing it. O(1) is 
>> O(1) is O(1). Besides AUTHENTICATE disturbs compression by using 
>> base64, so I doubt that it would be compressed very much.
>> 

I don't really see the need, and all my implementations handle, and 
expect, COMPRESS between TLS and SASL negotiations. (All of them also 
handle TLS, SASL, and COMPRESS simultaneously).

I don't think the difficulty lies in the implementation, I think it 
lies in the specification.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Ken Murchison <[email-masked]>
Date: Wed, 29 Nov 2006 17:01:16 -0500

Dave Cridland wrote:
>>> so personally I don't care about compressing it. O(1) is O(1) is 
>>> O(1). Besides AUTHENTICATE disturbs compression by using base64, so I 
>>> doubt that it would be compressed very much.
>>>

Just to be clear, you support:

STARTTLS
AUTHENTICATE
COMPRESS

and

STARTTLS
COMPRESS
AUTHENTICATE

but do NOT support:

COMPRESS
STARTTLS
AUTHENTICATE

---

From: Dave Cridland <[email-masked]>
Date: Wed, 29 Nov 2006 22:36:51 +0000

On Wed Nov 29 22:01:16 2006, Ken Murchison wrote:
>> I don't really see the need, and all my implementations handle, 
>> and expect, COMPRESS between TLS and SASL negotiations. (All of 
>> them also handle TLS, SASL, and COMPRESS simultaneously).
> 

No, that's supported too. My client doesn't do that, but it could do. 
It doesn't, primarily because that ordering doesn't make sense, since 
TLS might provide compression anyway, removing the need for the 
additional round-trip. (Assuming your TLS library bothers to tell 
you, of course).

It would, however, be really difficult to support if TLS negotiation 
happened above the compression layer - the negotiation would be hard, 
but renegotiations would be exceedingly painful to deal with. That's 
why I mentioned this edge-case a while back - it's obvious what 
should happen, but it's difficult to put into words. What about:

Independent of the ordering of the STARTTLS, COMPRESS, and 
AUTHENTICATE commands, the ordering of the resultant layers is 
always, from top to bottom: IMAP, COMPRESS, SASL, TLS, TCP. For all 
these commands, the layers exist after the command has successfully 
completed; in particular this means that SASL negotiation occurs in 
the IMAP layer, and therefore will be compressed by any COMPRESS 
layer present, then encrypted by any TLS layer present, and finally 
transmitted by TCP. TLS negotiation happens after the STARTTLS 
command, within the new TLS layer.

Dave.

---

From: Martin Konold <[email-masked]>
Date: Thu, 30 Nov 2006 00:18:38 +0100

Am Mittwoch, 29. November 2006 23:36 schrieb Dave Cridland:

Hi,

> > AUTHENTICATE

I propose not support COMPRESS before STARTTLS for security reasons. 
IMHO this would add an unnecessary extra attack vector without good reason.

The server administrator should be able to enforce the certificate exchange as 
soon as possible in order to limit many potential attacks to authenticate 
users. (think about client certifcates)

> always, from top to bottom: IMAP, COMPRESS, SASL, TLS, TCP.

I fully agree.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker

---

From: "Ben Last" <[email-masked]>
Date: Thu, 30 Nov 2006 08:06:21 -0000

>From: Dave Cridland [mailto:[email-masked]] 
>What about:

>Independent of the ordering of the STARTTLS, COMPRESS, and AUTHENTICATE
commands, the ordering
>of the resultant layers is always, from top to bottom: IMAP, COMPRESS,
SASL, TLS, TCP. For all
>these commands, the layers exist after the command has successfully
completed; in particular
>this means that SASL negotiation occurs in the IMAP layer, and
therefore will be compressed by
>any COMPRESS layer present, then encrypted by any TLS layer present,
and finally transmitted
>by TCP. TLS negotiation happens after the STARTTLS command, within the
new TLS layer.

Now that is very good; makes the ordering clear and also provides a
model of how the protocols encapsulate each other.  Fully agree.

Regards
Ben

Ben Last
R&D Manager
EMCC Software Ltd