Subject: Re: [NNTP] New draft for COMPRESS (-01)

From: Ken Murchison <[email-masked]>
Date: Tue, 02 Feb 2010 15:57:33 -0500

Julien ÉLIE wrote:
> Hi Ken,
> 
>>   A server MUST NOT return the COMPRESS or
>>   STARTTLS capability labels in response to a CAPABILITIES command
>>   received after a compression layer is active, and a server MUST reply
>>   with a 502 response code if a syntactically valid COMPRESS or
>>   STARTTLS command is received while a compression layer is already
>>   active.
> 
> I think it is too strong and that STARTTLS may be returned by a server
> that knows it can negotiate a TLS layer without compression.
> 
> See for instance in OpenSSL 1.0.0 (yes, the new upcoming version):
> 
>  *) New option SSL_OP_NO_COMP to disable use of compression selectively
>     in SSL structures.  New SSL ctrl to set maximum send fragment size.
>     Save memory by seeting the I/O buffer sizes dynamically instead of
>     using the maximum available value.
>     [Steve Henson]
> 
> 
> So a news server can decide to return STARTTLS if SSL_OP_NO_COMP
> is available.  Otherwise, it does not return it after a successful
> use of COMPRESS.

The problem is that whether or not TLS compression is supported and/or 
it can be dynamically [en|dis]abled and/or the compression parameters 
can be dynamically changed is completely dependent on the TLS 
implementation.  I don't want, nor do I think we should, write a 
specification that has different rules depending on what capabilities 
the TLS implementation possesses.

The IMAP COMPRESS spec has a simpler rule in that COMPRESS can only be 
used after authentication.  Since TLS, if used, MUST occur before 
authentication, it also MUST occur before COMPRESS.  I'm trying to 
follow the same principal with NNTP COMPRESS, but the fact that 
authentication isn't required makes things difficult.

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