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

From: Randall Gellens <[email-masked]>
Date: Mon, 2 Oct 2006 16:20:44 -0700

One other (besides Tony's) nit in Section 7:

     unlikely that another compression mechanism
     algorithm will be added

Please delete "algorithm".

I know this has been discussed before, and if you're sick of it and 
want to just leave it as-is that's fine, but I think this wording in 
Section 3 is awkward:

     When COMPRESS is combined with TLS or [SASL] layers, the order of
     processing data to be sent SHALL be to first COMPRESS, then SASL,
     and finally TLS. When receiving data, the processing order MUST be
     reversed. This ensures that data is compressed before it is
     encrypted, independent of the order in which the client issues
     COMPRESS, AUTHENTICATE, and STARTTLS.

It seems strange to me because of the usage of "SASL" and "TLS" as 
verbs, and the potential ambiguity of "SASL" -- is it the 
authentication exchange or a security layer?  I'd assume a SASL 
authentication exchange would be compressed if COMPRESS were issued 
before AUTHENTICATE, and so this text refers to any security layer 
that was also negotiated in SASL, and I think most implementers would 
come to the same conclusion (and the initial wording implies this as 
well), but it might be nice to make it more clear.

Perhaps something along the lines of:

When COMPRESS is combined with TLS or [SASL] layers, the sending 
order of the three extensions MUST be first COMPRESS, then SASL, and 
finally TLS.  That is, before data is transmitted it is first 
compressed.  Second, if a SASL security layer has been negotiated, 
the compressed data is then signed and/or encrypted accordingly. 
Third, if a TLS security layer has been negotiated, it is signed 
and/or encrypted accordingly.  When receiving data, the processing 
order MUST be reversed.  This ensures that before sending, data is 
compressed before it is encrypted, independent of the order in which 
the client issues COMPRESS, AUTHENTICATE, and STARTTLS.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lansing Residents Can Drop Off Trees
--Newspaper headline

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 3 Oct 2006 09:24:33 -0700

At 4:20 PM -0700 10/2/06, Randall Gellens wrote:

> order of the three extensions MUST be first COMPRESS, then SASL, 
> and finally TLS.  That is, before data is transmitted it is first 
> compressed before it is encrypted, independent of the order in 
> which the client issues COMPRESS, AUTHENTICATE, and STARTTLS.

Perhaps, just to make it somewhat more clear:

When COMPRESS is combined with TLS or [SASL] security layers, the 
sending order of the three extensions MUST be first COMPRESS, then 
SASL, and finally TLS.  That is, before data is transmitted it is 
first compressed.  Second, if a SASL security layer has been 
negotiated, the compressed data is then signed and/or encrypted 
accordingly. Third, if a TLS security layer has been negotiated, the 
data from the second step is signed and/or encrypted accordingly. 
When receiving data, the processing order MUST be reversed.  This 
ensures that before sending, data is compressed before it is 
encrypted, independent of the order in which the client issues 
COMPRESS, AUTHENTICATE, and STARTTLS.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
razbliuto (ros-blee-OO-toe; Russian; noun): the feeling a person
retains for someone he or she once loved.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Oct 2006 19:14:41 +0100

Randall Gellens wrote:

> data from the second step is signed and/or encrypted accordingly. When 
> receiving data, the processing order MUST be reversed.  This ensures 
> that before sending, data is compressed before it is encrypted, 
> independent of the order in which the client issues COMPRESS, 
> AUTHENTICATE, and STARTTLS.

I like this.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 3 Oct 2006 11:33:35 -0700

> accordingly. Third, if a TLS security layer has been negotiated, 
> the data from the second step is signed and/or encrypted 
> accordingly. When receiving data, the processing order MUST be 
> reversed.  This ensures that before sending, data is compressed 
> before it is encrypted, independent of the order in which the 
> client issues COMPRESS, AUTHENTICATE, and STARTTLS.

One (hopefully last) tweak: change "second step" to "previous step" 
(since if there is no SASL layer, the previous step is the first, not 
the second).

That would make it:

data from the previous step is signed and/or encrypted accordingly. 
encrypted, independent
-------------- Randomly-selected tag: ---------------
The whole dream of democracy is to raise the proletarian to the level
of stupidity attained by the bourgeois.            --Gustave Flaubert

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 3 Oct 2006 21:21:51 +0200

> (since if there is no SASL layer, the previous step is the first, not 
...

I used this. Thank you.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Thu, 05 Oct 2006 11:16:05 +0100

>> (since if there is no SASL layer, the previous step is the first, 

With SASL, the negotiation takes place above the compression layer, 
but the security layer (if any) happens below the compression.

With TLS, I assume the negotiation happens below the compression 
layer, if any, not above.

I can't find anything that explicitly tells me about this, though.

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: Randall Gellens <[email-masked]>
Date: Thu, 5 Oct 2006 10:48:17 -0700

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

> 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.)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The brain is a wonderful organ; it starts working the moment you get
up in the morning, and does not stop until you get to work.
                                                      --Robert Frost