[TLS] Compression along with TLS in NNTP

[Julien ÉLIE <[e-mail]>]

Hi all,

Last year, in September 2015, we spoke about the removal of TLS-level 
compression in TLS 1.2.
NNTP was relying on this feature provided by previous TLS versions to 
compress data.  We agreed that the right move was to standardize a new 
NNTP command.  It is what we finally did with the COMPRESS extension.
Interoperability is proven:  two news servers (INN, Cyrus NNTP) and a 
news client (flnews) have already implemented it.  It also works fine 
with Python nntplib+zlib libraries.

Here is the latest version of the draft:
     https://tools.ietf.org/html/draft-murchison-nntp-compress-03

If you have any comments, please don't hesitate to tell.


Especially, I have a question:

    o  How are TLS (and SASL) specific exchanges supposed to be handled?
       Should it be mentioned in the RFC that they are outside the scope
       of NNTP compression?  (I speak of stuff like TLS handshakes,
       renegotiations, etc. that can occur after the use of COMPRESS.
       OpenSSL may use SSL_read/SSL_write on its own, mayn't it?  And it
       does not know that it should compress data...)




Here is an extract of the paragraphs dealing with TLS in the draft, so 
that you can easily see what to comment (wording improvement, missing 
stuff...).


    The point of COMPRESS as an NNTP extension is to behave as a
    transport layer, similar to STARTTLS [RFC4642].  Compression can
    therefore benefit to all NNTP commands sent or received after the use
    of COMPRESS.

[...]

1.1.  About TLS-level Compression

    Though data compression is made possible via the use of TLS with NNTP
    [RFC4642], the best current practice is to disable TLS-level
    compression as explained in Section 3.3 of [RFC7525].  The COMPRESS
    command will permit to keep the compression facility in NNTP and
    control when it is available during a connection.

    Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the
    following advantages:

    o  COMPRESS can be implemented easily both by NNTP servers and
       clients.

    o  COMPRESS benefits from an intimate knowledge of the NNTP
       protocol's state machine, allowing for dynamic and aggressive
       optimization of the underlying compression algorithm's parameters.

    o  COMPRESS can be activated after authentication has completed thus
       reducing the chances that authentication credentials can be leaked
       via for instance a CRIME attack ([RFC7457] Section 2.6).

[...]

2.2.2.  Description

[...]

    Both the client and the server MUST know if there is a compression
    layer active (for instance via the previous use of the COMPRESS
    command or the negotiation of a TLS-level compression [RFC3749]).  A
    client MUST NOT attempt to activate compression or negotiate a TLS
    layer (for instance via the use of the COMPRESS or STARTTLS [RFC4642]
    commands) if a compression layer is already active.  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.

[...]

6.  Security Considerations

    Security issues are discussed throughout this document.

    In general, the security considerations of the NNTP core
    specification ([RFC3977] Section 12) and the DEFLATE compressed data
    format specification ([RFC1951] Section 6) are applicable here.

    Implementers should be aware that combining compression with
    encryption like TLS can sometimes reveal information that would not
    have been revealed without compression, as explained in Section 6 of
    [RFC3749].  As a matter of fact, adversaries that observe the length
    of the compressed data might be able to derive information about the
    corresponding uncompressed data.  The CRIME and the BREACH attacks
    ([RFC7457] Section 2.6) are examples of such case.

    In order to help mitigate leaking authentication credentials, this
    document states in Section 2.2.2 that authentication SHOULD NOT be
    attempted when a compression layer is active.  Therefore, when a
    client wants to authenticate, compress data, and negotiate a secure
    TLS layer (without TLS-level compression) in the same NNTP
    connection, it SHOULD use the STARTTLS, AUTHINFO, and COMPRESS
    commands in that order.  Of course instead of using the STARTTLS
    command, a client can also use implicit TLS, that is to say it begins
    the TLS negotiation immediately upon connection on a separate port
    dedicated to NNTP over TLS.

    NNTP commands other than AUTHINFO are not believed to divulgate
    confidential information as far as public Netnews newsgroups and
    articles are concerned.  That is why this specification only adds a
    restriction to the use of AUTHINFO when a compression layer is
    active.  In case private and confidential newsgroups or articles are
    accessed, a server SHOULD NOT allow compression, and a client SHOULD
    NOT attempt to activate compression, for the same reasons as
    mentioned above in this Section.

    Implementations MUST support a configuration where compression can be
    easily disabled.

    Future extensions to NNTP that define commands conveying confidential
    data SHOULD ensure to state that they SHOULD NOT be used along with
    compression.



Thanks again for your useful comments!

-- 
Julien ÉLIE

« Pourvu que ça dure ! » (Letizia Bonaparte)