Network News Transfer Protocol (NNTP) Extension for Compression
Extracted elements (27)
A server can improve compression efficiency and CPU performance by adjusting the DEFLATE compression level (e.g., setting it to 0) at the start of incompressible non-text multi-line data blocks such as yEnc-encoded attachments, preventing wasted CPU cycles on incompressible data.
COMPRESS is preferred over TLS-level compression because: it can be implemented more easily by both clients and servers; it benefits from intimate knowledge of NNTP's state machine for dynamic optimization; and it can be activated after authentication, reducing exposure to CRIME-style attacks that TLS-level compression cannot avoid.
Only one mandatory compression algorithm (DEFLATE) is specified to increase interoperability by minimizing the number of different algorithms that implementations must support. DEFLATE is standard, widely available, and fairly efficient.
The COMPRESS command enables compression for both client and server traffic, unlike legacy unstandardized commands (XZVER, XZHDR, XFEATURE COMPRESS, MODE COMPRESS) which enabled compression only for server responses. This removes the constraint of implementing compression separately in each NNTP command.
For DEFLATE via zlib, the windowBits value MUST be in the range -8 to -15 for deflateInit2(); the windowBits value SHOULD be -15 for inflateInit2(), otherwise it will not be able to decompress a stream with a larger window size, reducing interoperability.
Private compression algorithms with unregistered names are allowed, but SHOULD NOT be used because it is difficult to achieve interoperability with them. Different entries in the 'NNTP Compression Algorithms' registry MUST use different names.
All data submitted for compression MUST be included in the compressed output and appropriately flushed so that the receiving decompressor can completely decompress it. The receiving decompressor MUST automatically adjust to the compression parameters selected by the sender.
Authentication MUST NOT be attempted after a successful use of the COMPRESS command to help mitigate leaking authentication credentials via attacks such as CRIME. A server MUST either list the AUTHINFO capability with no arguments or not advertise it at all after successful COMPRESS.
Cached results of CAPABILITIES from a previous session MUST NOT be relied on, as the COMPRESS command is related to security because it can weaken encryption.
If a compression layer is already active, a server MUST reply with a 502 response code if a syntactically valid COMPRESS or STARTTLS command is received, and MUST NOT return the COMPRESS or STARTTLS capability labels in response to a CAPABILITIES command.
Implementations SHOULD NOT automatically enable compression when a security layer is active unless the user explicitly enabled it with the knowledge that compression may weaken the confidentiality of the security layer.
Implementations SHOULD NOT compress confidential data together with public data when a TLS or SASL security layer is active, as adversaries observing compressed data length might derive information about confidential content.
The client MUST NOT issue a MODE READER command after activating a compression layer, and a server MUST NOT advertise the MODE-READER capability.
The COMPRESS capability MUST NOT be advertised once a compression layer is active. The capability MAY be advertised both before and after any use of the MODE READER command with the same semantics.
The COMPRESS command MUST NOT be pipelined. The client MUST NOT send any further commands until it has seen the result of COMPRESS.
The DEFLATE algorithm (defined in RFC 1951) MUST be implemented as part of the COMPRESS extension. It MUST be supported and listed in the advertisement of the COMPRESS extension.
Unrecognized compression algorithms in the COMPRESS capability advertisement MUST be ignored by the client.
When a client wants to authenticate, compress data, and negotiate a TLS security layer (without TLS-level compression) in the same NNTP connection, it MUST use the STARTTLS, AUTHINFO, and COMPRESS commands in that order.
When COMPRESS is combined with TLS or SASL security layers, the processing order MUST be first COMPRESS, then SASL, and finally TLS. When receiving data, the processing order MUST be reversed.
When compression is active and either the client or server receives invalid or corrupted compressed data, the receiving end immediately closes the connection, in response to which the sending end will do the same.
The COMPRESS capability label contains a whitespace-separated list of available compression algorithms. Algorithm names are case-sensitive strings of 1 to 20 characters consisting of uppercase letters, digits, hyphens, and/or underscores (e.g., 'DEFLATE').
The COMPRESS command takes a single parameter (the algorithm name, e.g., 'DEFLATE') and returns 206 (compression active), 403 (unable to activate), or 502 (command unavailable if a compression layer is already active). Response 501 is used for syntactically invalid algorithm names and 503 for unsupported algorithms.
This document creates the 'NNTP Compression Algorithms' registry maintained by IANA at iana.org/assignments/nntp-parameters. New algorithms are registered on a First Come First Served basis. Algorithm names are 1-20 characters of uppercase letters, digits, hyphens, and/or underscores. Registrations MUST NOT be deleted; obsolete algorithms are marked OBSOLETE.
This document registers DEFLATE in the 'NNTP Compression Algorithms' registry with intended usage COMMON, change controller IESG, and a note that it is mandatory to implement. It also registers the COMPRESS capability label in the 'NNTP Capability Labels' registry.
Combining compression with encryption can reveal information that would not have been revealed without compression; adversaries observing the length of compressed data may derive information about the uncompressed data. The CRIME and BREACH attacks are examples of this. To mitigate, authentication MUST NOT be attempted after successful use of COMPRESS.
It is preferable not to compress the contents of two distinct confidential articles together; adversaries might derive information if they share common header fields or body lines. This can be mitigated with DEFLATE by clearing the compression dictionary (Z_FULL_FLUSH) between confidential articles.
A compression layer is either inactive (initial state) or active (after successful COMPRESS or TLS-level compression negotiation). In the active state: COMPRESS, STARTTLS, AUTHINFO (with arguments), and MODE READER commands are prohibited; the server must not advertise the COMPRESS, STARTTLS, or MODE-READER capabilities.