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)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls