[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 8054

Independent Submission                                      K. Murchison
Internet-Draft                                Carnegie Mellon University
Intended status: Standards Track                       November 12, 2015
Expires: May 15, 2016


    Network News Transfer Protocol (NNTP) Extension for Compression
                    draft-murchison-nntp-compress-02

Abstract

   This memo defines an extension to the Network News Transport Protocol
   (NNTP) to allow a connection to be effectively and efficiently
   compressed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 15, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Murchison                 Expires May 15, 2016                  [Page 1]


Internet-Draft       NNTP Extension for Compression        November 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  The COMPRESS Extension  . . . . . . . . . . . . . . . . . . .   3
     2.1.  Advertising the COMPRESS Extension  . . . . . . . . . . .   3
     2.2.  COMPRESS Command  . . . . . . . . . . . . . . . . . . . .   4
       2.2.1.  Usage . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.2.  Description . . . . . . . . . . . . . . . . . . . . .   4
       2.2.3.  Examples  . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Compression Efficiency  . . . . . . . . . . . . . . . . . . .   8
   4.  Augmented BNF Syntax for the COMPRESS Extension . . . . . . .   9
     4.1.  Commands  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Capability entries  . . . . . . . . . . . . . . . . . . .  10
     4.3.  General Non-terminals . . . . . . . . . . . . . . . . . .  10
   5.  Summary of Response Codes . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  NNTP Compression Algorithm Registry . . . . . . . . . . .  10
       7.1.1.  Algorithm Name Registration Procedure . . . . . . . .  11
       7.1.2.  Comments on Algorithm Registrations . . . . . . . . .  12
       7.1.3.  Change Control  . . . . . . . . . . . . . . . . . . .  12
     7.2.  Registration of the DEFLATE Compression Algorithm . . . .  12
     7.3.  Registration of the NNTP COMPRESS Extension . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  16
   Appendix B.  Document History (to be removed by RFC Editor before
                publication) . . . . . . . . . . . . . . . . . . . .  16
     B.1.  Changes since -01 . . . . . . . . . . . . . . . . . . . .  16
     B.2.  Changes since -00 . . . . . . . . . . . . . . . . . . . .  17
   Appendix C.  Issues to be addressed . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The goal of COMPRESS is to reduce the bandwidth usage of NNTP.

   Compared to PPP compression [RFC1962] and modem-based compression
   ([MNP] and [V42bis]), COMPRESS offers greater compression efficiency.
   COMPRESS can be used together with Transport Layer Security (TLS)
   [RFC5246], Simple Authentication and Security Layer (SASL) encryption
   [RFC4422], Virtual Private Networks (VPNs), etc.

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




Murchison                 Expires May 15, 2016                  [Page 2]


Internet-Draft       NNTP Extension for Compression        November 2015


   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 a CRIME attack [RFC7457].

   Also note that best current practice is to disable TLS-level
   compression [RFC7525].

   In order to increase interoperability, it is desirable to have as few
   different compression algorithms as possible, so this document
   specifies only one.  The DEFLATE algorithm (defined in [RFC1951]) is
   standard, widely available and fairly efficient, and MUST be
   implemented as part of this extension.

1.1.  Conventions Used in This Document

   The notational conventions used in this document are the same as
   those in [RFC3977] and any term not defined in this document has the
   same meaning as in that one.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In the examples, commands from the client are indicated with [C], and
   responses from the server are indicated with [S].

2.  The COMPRESS Extension

   The COMPRESS extension is used to enable data compression on an NNTP
   connection.

   This extension provides a new COMPRESS command and has capability
   label COMPRESS.

2.1.  Advertising the COMPRESS Extension

   A server supporting the COMPRESS command as defined in this document
   will advertise the "COMPRESS" capability label in response to the
   CAPABILITIES command ([RFC3977] Section 5.2).  This capability MAY be
   advertised both before and after any use of the MODE READER command
   ([RFC3977] Section 5.3), with the same semantics.



Murchison                 Expires May 15, 2016                  [Page 3]


Internet-Draft       NNTP Extension for Compression        November 2015


   The COMPRESS capability label contains a whitespace-separated list of
   available compression algorithms.  This document defines one
   compression algorithm: DEFLATE.  This algorithm is mandatory to
   implement and MUST be supported in order to advertise the COMPRESS
   extension.

   Future extensions may add additional compression algorithms to this
   capability.  Unrecognized algorithms MUST be ignored by the client.

   Example:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] IHAVE
   [S] COMPRESS DEFLATE X-SHRINK
   [S] LIST ACTIVE NEWSGROUPS
   [S] .

2.2.  COMPRESS Command

2.2.1.  Usage

   This command MUST NOT be pipelined.

   Syntax
      COMPRESS algorithm

   Responses
      206 Compression active
      403 Unable to activate compression
      502 Command unavailable [1]

   [1] If a compression layer is already active, COMPRESS is not a valid
       command (see Section 2.2.2).

   Parameters
      algorithm = Name of compression algorithm: "DEFLATE"

2.2.2.  Description

   The COMPRESS command instructs the server to use the named
   compression algorithm ("DEFLATE" is the only one defined in this
   document) for all commands and/or responses after COMPRESS.

   The client MUST NOT send any further commands until it has seen the
   result of COMPRESS.



Murchison                 Expires May 15, 2016                  [Page 4]


Internet-Draft       NNTP Extension for Compression        November 2015


   If the requested compression algorithm is invalid (e.g., is not
   supported), the server MUST reject the COMPRESS command with a 503
   response ([RFC3977] Section 3.2.1).  If the server is unable to
   activate compression for any reason (e.g., a server configuration or
   resource problem), the server MUST reject the COMPRESS command with a
   403 response ([RFC3977] Section 3.2.1).  Otherwise, the server issues
   a 206 response and the compression layer takes effect for both client
   and server immediately following the CRLF of the success reply.

   Both the client and the server MUST know if there is a compression
   layer active.  A client MUST NOT attempt to activate compression (via
   either 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.

   In order help mitigate leaking authentication credentials via a CRIME
   attack [CRIME], a server SHOULD NOT return any arguments with the
   AUTHINFO capability label in response to a CAPABILTIES command
   received after a compression layer is active.  In this case, a client
   SHOULD NOT attempt to utilize any AUTHINFO commands.

   For DEFLATE [RFC1951] (as for many other compression mechanisms), the
   compressor can trade speed against quality.  The decompressor MUST
   automatically adjust to the parameters selected by the sender.
   Consequently, the client and server are both free to pick the best
   reasonable rate of compression for the data they send.

   When COMPRESS is combined with TLS [RFC5246] or SASL [RFC4422]
   security layers, the processing order of the three layers 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 previous 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 the COMPRESS, AUTHINFO SASL [RFC4643], and STARTTLS
   [RFC4642] commands.








Murchison                 Expires May 15, 2016                  [Page 5]


Internet-Draft       NNTP Extension for Compression        November 2015


2.2.3.  Examples

   Example of layering TLS and NNTP compression:

 [C] CAPABILITIES
 [S] 101 Capability list:
 [S] VERSION 2
 [S] READER
 [S] STARTTLS
 [S] AUTHINFO
 [S] COMPRESS DEFLATE
 [S] .
 [C] STARTTLS
 [S] 382 Continue with TLS negotiation
 [TLS negotiation without compression occurs here]
 [Following successful negotiation, all traffic is encrypted]
 [C] CAPABILITIES
 [S] 101 Capability list:
 [S] VERSION 2
 [S] READER
 [S] AUTHINFO USER
 [S] COMPRESS DEFLATE
 [S] .
 [C] AUTHINFO USER fred
 [S] 381 Enter passphrase
 [C] AUTHINFO PASS flintstone
 [S] 281 Authentication accepted
 [C] COMPRESS DEFLATE
 [S] 206 Compression active
 [From this point on, all traffic is compresssed before being encrypted]

   Example of a server failing to activate compression:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] COMPRESS DEFLATE
   [S] .
   [C] COMPRESS DEFLATE
   [S] 403 Unable to activate compression

   Example of attempting to use an unsupported compression algorithm:








Murchison                 Expires May 15, 2016                  [Page 6]


Internet-Draft       NNTP Extension for Compression        November 2015


   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] COMPRESS DEFLATE
   [S] .
   [C] COMPRESS X-SHRINK
   [S] 503 Compression algorithm not supported

   Examples of a server refusing to compress twice:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] STARTTLS
   [S] COMPRESS DEFLATE
   [S] .
   [C] STARTTLS
   [S] 382 Continue with TLS negotiation
   [TLS negotiation with compression occurs here]
   [Following successful negotiation, all traffic is protected by TLS]
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] .
   [C] COMPRESS DEFLATE
   [S] 502 Compression already active via TLS

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] STARTTLS
   [S] COMPRESS DEFLATE
   [S] .
   [C] COMPRESS DEFLATE
   [S] 206 Compression active
   [From this point on, all traffic is compresssed]
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] IHAVE
   [S] .
   [C] STARTTLS
   [S] 502 DEFLATE compression already active




Murchison                 Expires May 15, 2016                  [Page 7]


Internet-Draft       NNTP Extension for Compression        November 2015


   Example of a server not advertising AUTHINFO mechanisms after
   compression has been activated:

   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] AUTHINFO USER
   [S] COMPRESS DEFLATE
   [S] .
   [C] COMPRESS DEFLATE
   [S] 206 Compression active
   [From this point on, all traffic is compresssed]
   [C] CAPABILITIES
   [S] 101 Capability list:
   [S] VERSION 2
   [S] READER
   [S] AUTHINFO
   [S] .

3.  Compression Efficiency

   This section is informative, not normative.

   NNTP poses some unusual problems for a compression layer.

   Upstream traffic is fairly simple.  Most NNTP clients send the same
   few commands again and again, so any compression algorithm that can
   exploit repetition works efficiently.  The article posting and
   transfer commands (e.g., POST, IHAVE, and TAKETHIS [RFC4644]) are
   exceptions; clients that send many article posting or transfer
   commands may want to surround large multi-line data blocks with
   flushes in the same way as is recommended for servers later in this
   section.

   Downstream traffic has the unusual property that several kinds of
   data are sent, confusing all dictionary-based compression algorithms.

   One type is NNTP simple responses and NNTP multi-line responses not
   related to article header/body retrieval (e.g, CAPABILITIES, GROUP,
   LISTGROUP, LAST, NEXT, STAT, DATE, NEWNEWS, NEWGROUPS, LIST, CHECK
   [RFC4644], etc).  These are highly compressible; zlib using its least
   CPU-intensive setting compresses typical responses to 25-40% of their
   original size.

   Another type is article headers (as retrieved via the HEAD, HDR,
   OVER, or ARTICLE commands).  These are equally compressible, and
   benefit from using the same dictionary as the NNTP responses.



Murchison                 Expires May 15, 2016                  [Page 8]


Internet-Draft       NNTP Extension for Compression        November 2015


   A third type is article body text (as retrieved via the BODY or
   ARTICLE commands).  Text is usually fairly short and includes much
   ASCII, so the same compression dictionary will do a good job here,
   too.  When multiple messages in the same thread are read at the same
   time, quoted lines, etc. can often be compressed almost to zero.

   Finally, attachments (non-text article bodies retrieved via the BODY
   and ARTICLE commands) are transmitted in encoded form, usually Base64
   [RFC4648], UUencode [IEEE.1003-2.1992], or yEnc [yEnc].

   When attachments are retrieved, DEFLATE may be able to compress them,
   but the format of the attachment's encoding is usually not NNTP-like,
   so the dictionary built while compressing NNTP does not help.  The
   compressor has to adapt its dictionary from NNTP to the attachment's
   encoding format, and then back.

   When attachments are retrieved in Base64 or UUencode form, these
   encodings add another problem.  8-bit compression algorithms such as
   DEFLATE work well on 8-bit file formats, however both Base64 and
   UUencode transform a file into something resembling 6-bit bytes,
   hiding most of the 8-bit file format from the compressor.

   When using the zlib library (see [RFC1951]), the functions
   deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
   implement this extension.  The windowBits value must be in the range
   -8 to -15 for deflateInit2(), or else it will use the wrong format.
   The windowBits value should be -15 for inflateInit2(), or else it
   will not be able to decompress a stream with a larger window size.
   deflateParams() can be used to improve compression rate and resource
   use.  The Z_FULL_FLUSH argument to deflate() can be used to clear the
   dictionary (the receiving peer does not need to do anything).

   A server can improve downstream compression if it hints to the
   compressor that the data type is about to change strongly, e.g., by
   sending a Z_FULL_FLUSH at the start and end of large non-text multi-
   line data blocks (before and after 'content-lines' in the definition
   of 'multi-line-data-block' in [RFC3977] Section 9.8).  Small multi-
   line data blocks are best left alone.  A possible boundary is 5kB.

4.  Augmented BNF Syntax for the COMPRESS Extension

   This section describes the syntax of the COMPRESS extension using
   ABNF [RFC7405] [RFC5234].  It extends the syntax in Section 9 of
   [RFC3977], and non-terminals not defined in this document are defined
   there.  The [RFC3977] ABNF should be imported first before attempting
   to validate these rules.





Murchison                 Expires May 15, 2016                  [Page 9]


Internet-Draft       NNTP Extension for Compression        November 2015


4.1.  Commands

   This syntax extends the non-terminal "command", which represents an
   NNTP command.

   command =/ compress-command

   compress-command = "COMPRESS" WS algorithm

4.2.  Capability entries

   This syntax extends the non-terminal "capability-entry", which
   represents a capability that may be advertised by the server.

   capability-entry =/ compress-capability

   compress-capability = "COMPRESS" 1*(WS algorithm)

4.3.  General Non-terminals

   algorithm = %s"DEFLATE" / 1*20alg-char  ; case-sensitive
   alg-char = UPPER / DIGIT / "-" / "_"

5.  Summary of Response Codes

   This section contains a list of each new response code defined in
   this document and indicates whether it is multi-line, which commands
   can generate it, what arguments it has, and what its meaning is.

   Response code 206
      Generated by: COMPRESS
      Meaning: Compression layer activated

6.  Security Considerations

   TODO

7.  IANA Considerations

7.1.  NNTP Compression Algorithm Registry

   The NNTP Compression Algorithm registry will be maintained by IANA.
   The registry will be available at <http://www.iana.org/assignments/
   nntp-compression-algorithms>.

   The purpose of this registry is not only to ensure uniqueness of
   values used to name NNTP compression algorithms, but also to provide




Murchison                 Expires May 15, 2016                 [Page 10]


Internet-Draft       NNTP Extension for Compression        November 2015


   a definitive reference to technical specifications detailing each
   NNTP compression algorithm available for use on the Internet.

   There is no naming convention for NNTP compression algorithms; any
   name that conforms to the syntax of a NNTP compression algorithm name
   can be registered.

   The procedure detailed in Section 7.1.1 is to be used for
   registration of a value naming a specific individual mechanism.

   Comments may be included in the registry as discussed in
   Section 7.1.2 and may be changed as discussed in Section 7.1.3.

7.1.1.  Algorithm Name Registration Procedure

   IANA will register new NNTP compression algorithm names on a First
   Come First Served basis, as defined in BCP 26 [RFC5226].  IANA has
   the right to reject obviously bogus registration requests, but will
   perform no review of claims made in the registration form.

   Registration of an NNTP compression algorithm is requested by filling
   in the following template and sending it via electronic mail to IANA
   at <iana@iana.org>:

   Subject: Registration of NNTP compression algorithm X

   NNTP compression algorithm name:

   Security considerations:

   Published specification (recommended):

   Contact for further information:

   Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)

   Owner/Change controller:

   Note: (Any other information that the author deems relevant may be
          added here.)

   While this registration procedure does not require expert review,
   authors of NNTP compression algorithms are encouraged to seek
   community review and comment whenever that is feasible.  Authors may
   seek community review by posting a specification of their proposed
   mechanism as an Internet-Draft.  NNTP compression algorithms intended
   for widespread use should be standardized through the normal IETF
   process, when appropriate.



Murchison                 Expires May 15, 2016                 [Page 11]


Internet-Draft       NNTP Extension for Compression        November 2015


7.1.2.  Comments on Algorithm Registrations

   Comments on a registered NNTP compression algorithm should first be
   sent to the "owner" of the algorithm and/or to the <ietf-
   nntp@lists.eyrie.org> mailing list.

   Submitters of comments may, after a reasonable attempt to contact the
   owner, request IANA to attach their comment to the NNTP compression
   algorithm registration itself by sending mail to <iana@iana.org>.  At
   IANA's sole discretion, IANA may attach the comment to the NNTP
   compression algorithm's registration.

7.1.3.  Change Control

   Once an NNTP compression algorithm registration has been published by
   IANA, the author may request a change to its definition.  The change
   request follows the same procedure as the registration request.

   The owner of an NNTP compression algorithm may pass responsibility
   for the algorithm to another person or agency by informing IANA; this
   can be done without discussion or review.

   The IESG may reassign responsibility for an NNTP compression
   algorithm.  The most common case of this will be to enable changes to
   be made to algorithms where the author of the registration has died,
   has moved out of contact, or is otherwise unable to make changes that
   are important to the community.

   NNTP compression algorithm registrations may not be deleted;
   algorithms that are no longer believed appropriate for use can be
   declared OBSOLETE by a change to their "intended usage" field; such
   algorithms will be clearly marked in the lists published by IANA.

   The IESG is considered to be the owner of all NNTP compression
   algorithms that are on the IETF standards track.

7.2.  Registration of the DEFLATE Compression Algorithm

   This section gives a formal definition of the DEFLATE compression
   algorithm as required by Section 7.1.1 for the IANA registry.

   NNTP compression algorithm name: DEFLATE

   Security considerations: See Section 6 of this document

   Published specification: This document

   Contact for further information: Author of this document



Murchison                 Expires May 15, 2016                 [Page 12]


Internet-Draft       NNTP Extension for Compression        November 2015


   Intended usage: COMMON

   Owner/Change controller: IESG <iesg@ietf.org>.

   Note: This algorithm is mandatory to implement

7.3.  Registration of the NNTP COMPRESS Extension

   This section gives a formal definition of the COMPRESS extension as
   required by Section 3.3.3 of [RFC3977] for the IANA registry.

   o  The COMPRESS extension allows an NNTP connection to be effectively
      and efficiently compressed.

   o  The capability label for this extension is "COMPRESS", whose
      arguments list the available compression algorithms.

   o  This extension defines one new command, COMPRESS, whose behavior,
      arguments, and responses are defined in Section 2.2.

   o  This extension does not associate any new responses with pre-
      existing NNTP commands.

   o  This extension does affect the overall behavior of both server and
      client, in that after successful use of the COMPRESS command, all
      communication is transmitted in a compressed format.

   o  This extension does not affect the maximum length of commands or
      initial response lines.

   o  This extension does not alter pipelining, but the COMPRESS command
      cannot be pipelined.

   o  Use of this extension does alter the capabilities list; once the
      COMPRESS command has been used successfully, the COMPRESS
      capability can no longer be advertised by CAPABILITIES.
      Additionally, the STARTTLS and MODE-READER capabilities MUST NOT
      be advertised after successful execution of the COMPRESS command.

   o  This extension does not cause any pre-existing command to produce
      a 401, 480, or 483 response.

   o  This extension is unaffected by any use of the MODE READER
      command, however the MODE READER command MUST NOT be used in the
      same session following a successful execution of the COMPRESS
      command.





Murchison                 Expires May 15, 2016                 [Page 13]


Internet-Draft       NNTP Extension for Compression        November 2015


   o  The STARTTLS command MUST NOT be used in the same session
      following a successful execution of the COMPRESS command.

   o  Published Specification: This document.

   o  Contact for Further Information: Author of this document.

   o  Change Controller: IESG <iesg@ietf.org>.

8.  References

8.1.  Normative References

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
              <http://www.rfc-editor.org/info/rfc1951>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3977]  Feather, C., "Network News Transfer Protocol (NNTP)", RFC
              3977, DOI 10.17487/RFC3977, October 2006,
              <http://www.rfc-editor.org/info/rfc3977>.

   [RFC4642]  Murchison, K., Vinocur, J., and C. Newman, "Using
              Transport Layer Security (TLS) with Network News Transfer
              Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
              2006, <http://www.rfc-editor.org/info/rfc4642>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
              RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
              7405, DOI 10.17487/RFC7405, December 2014,
              <http://www.rfc-editor.org/info/rfc7405>.







Murchison                 Expires May 15, 2016                 [Page 14]


Internet-Draft       NNTP Extension for Compression        November 2015


8.2.  Informative References

   [CRIME]    Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty
              Security Conference, 2012.

   [IEEE.1003-2.1992]
              Institute of Electrical and Electronics Engineers,
              "Information Technology - Portable Operating System
              Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)",
              IEEE Standard 1003.2, 1992.

   [MNP]      Held, G., "The Complete Modem Reference", Second Edition,
              Wiley Professional Computing, May 1994.

   [RFC1962]  Rand, D., "The PPP Compression Control Protocol (CCP)",
              RFC 1962, DOI 10.17487/RFC1962, June 1996,
              <http://www.rfc-editor.org/info/rfc1962>.

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
              2004, <http://www.rfc-editor.org/info/rfc3749>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, DOI
              10.17487/RFC4422, June 2006,
              <http://www.rfc-editor.org/info/rfc4422>.

   [RFC4643]  Vinocur, J. and K. Murchison, "Network News Transfer
              Protocol (NNTP) Extension for Authentication", RFC 4643,
              DOI 10.17487/RFC4643, October 2006,
              <http://www.rfc-editor.org/info/rfc4643>.

   [RFC4644]  Vinocur, J. and K. Murchison, "Network News Transfer
              Protocol (NNTP) Extension for Streaming Feeds", RFC 4644,
              DOI 10.17487/RFC4644, October 2006,
              <http://www.rfc-editor.org/info/rfc4644>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC4978]  Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
              DOI 10.17487/RFC4978, August 2007,
              <http://www.rfc-editor.org/info/rfc4978>.







Murchison                 Expires May 15, 2016                 [Page 15]


Internet-Draft       NNTP Extension for Compression        November 2015


   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
              RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
              Known Attacks on Transport Layer Security (TLS) and
              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
              February 2015, <http://www.rfc-editor.org/info/rfc7457>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [V42bis]   International Telecommunications Union, "Data compression
              procedures for data circuit-terminating equipment (DCE)
              using error correction procedures", ITU-T Recommendation
              V.42bis, January 1990.

   [yEnc]     Helbing, J., "yEnc - Efficient encoding for Usenet and
              eMail", March 2002,
              <http://www.yenc.org/yenc-draft.1.3.txt>.

Appendix A.  Acknowledgements

   This document draws heavily on ideas in [RFC4978] by Arnt Gulbrandsen
   and a large portion of this text was borrowed from that
   specification.

   The author would like to thank the following individuals for
   contributing their ideas and support for writing this specification:
   Russ Allbery, Michael Baeuerle, and Julien ELIE,

Appendix B.  Document History (to be removed by RFC Editor before
             publication)

B.1.  Changes since -01

   o  Switched to using 206 response code when compression has been
      activated.

   o  Added text stating that TLS-level compression is susceptible to
      CRIME attack and current BCP is to disable it.

   o  Added text stating that AUTHINFO shouldn't be advertised or used
      after COMPRESS to prevent possible CRIME attack (with example).



Murchison                 Expires May 15, 2016                 [Page 16]


Internet-Draft       NNTP Extension for Compression        November 2015


   o  Added text stating that a windowBits value of -15 should be used
      for inflateInit2().

   o  Minor editorial changes.

B.2.  Changes since -00

   o  Made DEFLATE the mandatory to implement compression algorithm.

   o  Removed the requirement that clients/servers implementing COMPRESS
      also implement TLS compression.

   o  Added an example of a client trying to use an unsupported
      compression algorithm.

   o  Rewrote Compression Efficiency (Section 3) as follows:

      *  Included a sample listing of which NNTP commands produce which
         type of data to be compressed.

      *  Removed discussion of attachments in binary form and
         incompressible file formats.

      *  Mentioned UUencode and yEnc encoding of attachments.

   o  Added IANA registry of NNTP compression algorithms.

   o  Miscellaneous editorial changes submitted by Julien Elie.

Appendix C.  Issues to be addressed

   o  Should we restrict the ABNF for compression algorithms?  We
      currently use 'token' but that allows for UTF-8 chars and case-
      insensitivity.

Author's Address

   Kenneth Murchison
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA  15213
   US

   Phone: +1 412 268 1982
   Email: murch@andrew.cmu.edu






Murchison                 Expires May 15, 2016                 [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/