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

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 1 Dec 2006 13:01:23 +0100

Dave Cridland writes:
> 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.

I don't mind using that text, but I'd like a little consensus first.

On one hand, we have Ken, Martin and to some degree me, who would like 
to make COMPRESS a command-auth. Martin put forward an argument for 
that: command-auth makes it impossible to attack the compression 
library unauthenticated. (For servers which also offer to compress via 
TLS this doens't apply.) I like command-auth because it avoids so much 
hair-splitting in the definition (as Dave too says).

On the other hand, we have Dave and Ben, who like the text above.

What do other people think? Lurkers of the world, stand up and be heard!

Arnt

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

---

From: Philip Guenther <[email-masked]>
Date: Fri, 1 Dec 2006 06:21:02 -0700

On Fri, 1 Dec 2006, Arnt Gulbrandsen wrote:
...
> On one hand, we have Ken, Martin and to some degree me, who would like to 
> make COMPRESS a command-auth. Martin put forward an argument for that: 
> command-auth makes it impossible to attack the compression library 
> unauthenticated.

I'll note that there's an I-D to standardize an SSH compression method 
("[email-masked]", IIRC) that delays compression until after 
authentication has succeeded, so there is precedent for this decision.

> (For servers which also offer to compress via TLS this doens't apply.)

The TLS server _could_ refuse to negotiate compression initially but then 
request a renegotiation after authentication to start compressing, though 
the additional RTTs would be annoying...

...
> What do other people think? Lurkers of the world, stand up and be heard!

I prefer command-auth.  I like the simplicity and the more paranoid 
security aspect.  I suspect that any authentication exchange that's large 
enough to be worth compressing will involve enough crypto goop to make 
compression almost worthless.  Running the SASL exchange in binary instead 
of base64 would be a better gain there...

Philip Guenther

---

From: "Ben Last" <[email-masked]>
Date: Fri, 1 Dec 2006 13:57:18 -0000

From: Arnt Gulbrandsen [mailto:[email-masked]] 
>On one hand, we have Ken, Martin and to some degree me, who would like
to make COMPRESS a command-auth...
>On the other hand, we have Dave and Ben, who like the text above.

Actually, I'm happy with either order.  What I like about the text is
that it clearly sets out both the order and the way in which the
protocols encapsulate each other.  I can see the logic for COMPRESS
being an auth command and have no problem with it :)

Cheers
b

Ben Last
R&D Manager
EMCC Software Ltd

---

From: Ken Murchison <[email-masked]>
Date: Fri, 01 Dec 2006 08:59:55 -0500

Arnt Gulbrandsen wrote:
>> 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:
>>
>> 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 
>> the IMAP layer, and therefore will be compressed by any COMPRESS layer 
>> present, then encrypted by any TLS layer present, and finally 
> that: command-auth makes it impossible to attack the compression library 
> unauthenticated. (For servers which also offer to compress via TLS this 
> doens't apply.) I like command-auth because it avoids so much 

Yes, I'm in favor of making COMPRESS a command-auth, but I won't stand 
in the way of allowing it before AUTHENTICATE.  Note that allowing it in 
between STARTTLS and AUTHENTICATE makes the ABNF a lot messier than 
simply making it a command-auth.

My main concern was disallowing it before STARTTLS, which we seem to 
have consensus on, correct?

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 01 Dec 2006 14:12:54 +0000

On Fri Dec  1 13:59:55 2006, Ken Murchison wrote:
> My main concern was disallowing it before STARTTLS, which we seem 
> to have consensus on, correct?

As I say, I don't see the need to mandate this, but I won't object to 
it strongly.

You actually want no STARTTLS after COMPRESS, by the way. STARTTLS 
might never happen.

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: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 1 Dec 2006 15:40:28 +0100

> As I say, I don't see the need to mandate this, but I won't object to 

I call that which I now see «rough consensus» and will post a draft update.

Arnt