idnits 2.17.1 draft-murchison-nntp-compress-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2015) is 3080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'C' is mentioned on line 342, but not defined == Missing Reference: 'S' is mentioned on line 347, but not defined -- Looks like a reference, but probably isn't: '1' on line 179 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission K. Murchison 3 Internet-Draft Carnegie Mellon University 4 Intended status: Standards Track November 12, 2015 5 Expires: May 15, 2016 7 Network News Transfer Protocol (NNTP) Extension for Compression 8 draft-murchison-nntp-compress-02 10 Abstract 12 This memo defines an extension to the Network News Transport Protocol 13 (NNTP) to allow a connection to be effectively and efficiently 14 compressed. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 15, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. The COMPRESS Extension . . . . . . . . . . . . . . . . . . . 3 53 2.1. Advertising the COMPRESS Extension . . . . . . . . . . . 3 54 2.2. COMPRESS Command . . . . . . . . . . . . . . . . . . . . 4 55 2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 4 57 2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Compression Efficiency . . . . . . . . . . . . . . . . . . . 8 59 4. Augmented BNF Syntax for the COMPRESS Extension . . . . . . . 9 60 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4.2. Capability entries . . . . . . . . . . . . . . . . . . . 10 62 4.3. General Non-terminals . . . . . . . . . . . . . . . . . . 10 63 5. Summary of Response Codes . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. NNTP Compression Algorithm Registry . . . . . . . . . . . 10 67 7.1.1. Algorithm Name Registration Procedure . . . . . . . . 11 68 7.1.2. Comments on Algorithm Registrations . . . . . . . . . 12 69 7.1.3. Change Control . . . . . . . . . . . . . . . . . . . 12 70 7.2. Registration of the DEFLATE Compression Algorithm . . . . 12 71 7.3. Registration of the NNTP COMPRESS Extension . . . . . . . 13 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 8.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 76 Appendix B. Document History (to be removed by RFC Editor before 77 publication) . . . . . . . . . . . . . . . . . . . . 16 78 B.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 16 79 B.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 17 80 Appendix C. Issues to be addressed . . . . . . . . . . . . . . . 17 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 The goal of COMPRESS is to reduce the bandwidth usage of NNTP. 87 Compared to PPP compression [RFC1962] and modem-based compression 88 ([MNP] and [V42bis]), COMPRESS offers greater compression efficiency. 89 COMPRESS can be used together with Transport Layer Security (TLS) 90 [RFC5246], Simple Authentication and Security Layer (SASL) encryption 91 [RFC4422], Virtual Private Networks (VPNs), etc. 93 Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the 94 following advantages: 96 o COMPRESS can be implemented easily both by NNTP servers and 97 clients. 99 o COMPRESS benefits from an intimate knowledge of the NNTP 100 protocol's state machine, allowing for dynamic and aggressive 101 optimization of the underlying compression algorithm's parameters. 103 o COMPRESS can be activated after authentication has completed thus 104 reducing the chances that authentication credentials can be leaked 105 via a CRIME attack [RFC7457]. 107 Also note that best current practice is to disable TLS-level 108 compression [RFC7525]. 110 In order to increase interoperability, it is desirable to have as few 111 different compression algorithms as possible, so this document 112 specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is 113 standard, widely available and fairly efficient, and MUST be 114 implemented as part of this extension. 116 1.1. Conventions Used in This Document 118 The notational conventions used in this document are the same as 119 those in [RFC3977] and any term not defined in this document has the 120 same meaning as in that one. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 In the examples, commands from the client are indicated with [C], and 127 responses from the server are indicated with [S]. 129 2. The COMPRESS Extension 131 The COMPRESS extension is used to enable data compression on an NNTP 132 connection. 134 This extension provides a new COMPRESS command and has capability 135 label COMPRESS. 137 2.1. Advertising the COMPRESS Extension 139 A server supporting the COMPRESS command as defined in this document 140 will advertise the "COMPRESS" capability label in response to the 141 CAPABILITIES command ([RFC3977] Section 5.2). This capability MAY be 142 advertised both before and after any use of the MODE READER command 143 ([RFC3977] Section 5.3), with the same semantics. 145 The COMPRESS capability label contains a whitespace-separated list of 146 available compression algorithms. This document defines one 147 compression algorithm: DEFLATE. This algorithm is mandatory to 148 implement and MUST be supported in order to advertise the COMPRESS 149 extension. 151 Future extensions may add additional compression algorithms to this 152 capability. Unrecognized algorithms MUST be ignored by the client. 154 Example: 156 [C] CAPABILITIES 157 [S] 101 Capability list: 158 [S] VERSION 2 159 [S] READER 160 [S] IHAVE 161 [S] COMPRESS DEFLATE X-SHRINK 162 [S] LIST ACTIVE NEWSGROUPS 163 [S] . 165 2.2. COMPRESS Command 167 2.2.1. Usage 169 This command MUST NOT be pipelined. 171 Syntax 172 COMPRESS algorithm 174 Responses 175 206 Compression active 176 403 Unable to activate compression 177 502 Command unavailable [1] 179 [1] If a compression layer is already active, COMPRESS is not a valid 180 command (see Section 2.2.2). 182 Parameters 183 algorithm = Name of compression algorithm: "DEFLATE" 185 2.2.2. Description 187 The COMPRESS command instructs the server to use the named 188 compression algorithm ("DEFLATE" is the only one defined in this 189 document) for all commands and/or responses after COMPRESS. 191 The client MUST NOT send any further commands until it has seen the 192 result of COMPRESS. 194 If the requested compression algorithm is invalid (e.g., is not 195 supported), the server MUST reject the COMPRESS command with a 503 196 response ([RFC3977] Section 3.2.1). If the server is unable to 197 activate compression for any reason (e.g., a server configuration or 198 resource problem), the server MUST reject the COMPRESS command with a 199 403 response ([RFC3977] Section 3.2.1). Otherwise, the server issues 200 a 206 response and the compression layer takes effect for both client 201 and server immediately following the CRLF of the success reply. 203 Both the client and the server MUST know if there is a compression 204 layer active. A client MUST NOT attempt to activate compression (via 205 either the COMPRESS or STARTTLS [RFC4642] commands) if a compression 206 layer is already active. A server MUST NOT return the COMPRESS or 207 STARTTLS capability labels in response to a CAPABILITIES command 208 received after a compression layer is active, and a server MUST reply 209 with a 502 response code if a syntactically valid COMPRESS or 210 STARTTLS command is received while a compression layer is already 211 active. 213 In order help mitigate leaking authentication credentials via a CRIME 214 attack [CRIME], a server SHOULD NOT return any arguments with the 215 AUTHINFO capability label in response to a CAPABILTIES command 216 received after a compression layer is active. In this case, a client 217 SHOULD NOT attempt to utilize any AUTHINFO commands. 219 For DEFLATE [RFC1951] (as for many other compression mechanisms), the 220 compressor can trade speed against quality. The decompressor MUST 221 automatically adjust to the parameters selected by the sender. 222 Consequently, the client and server are both free to pick the best 223 reasonable rate of compression for the data they send. 225 When COMPRESS is combined with TLS [RFC5246] or SASL [RFC4422] 226 security layers, the processing order of the three layers MUST be 227 first COMPRESS, then SASL, and finally TLS. That is, before data is 228 transmitted it is first compressed. Second, if a SASL security layer 229 has been negotiated, the compressed data is then signed and/or 230 encrypted accordingly. Third, if a TLS security layer has been 231 negotiated, the data from the previous step is signed and/or 232 encrypted accordingly. When receiving data, the processing order 233 MUST be reversed. This ensures that before sending, data is 234 compressed before it is encrypted, independent of the order in which 235 the client issues the COMPRESS, AUTHINFO SASL [RFC4643], and STARTTLS 236 [RFC4642] commands. 238 2.2.3. Examples 240 Example of layering TLS and NNTP compression: 242 [C] CAPABILITIES 243 [S] 101 Capability list: 244 [S] VERSION 2 245 [S] READER 246 [S] STARTTLS 247 [S] AUTHINFO 248 [S] COMPRESS DEFLATE 249 [S] . 250 [C] STARTTLS 251 [S] 382 Continue with TLS negotiation 252 [TLS negotiation without compression occurs here] 253 [Following successful negotiation, all traffic is encrypted] 254 [C] CAPABILITIES 255 [S] 101 Capability list: 256 [S] VERSION 2 257 [S] READER 258 [S] AUTHINFO USER 259 [S] COMPRESS DEFLATE 260 [S] . 261 [C] AUTHINFO USER fred 262 [S] 381 Enter passphrase 263 [C] AUTHINFO PASS flintstone 264 [S] 281 Authentication accepted 265 [C] COMPRESS DEFLATE 266 [S] 206 Compression active 267 [From this point on, all traffic is compresssed before being encrypted] 269 Example of a server failing to activate compression: 271 [C] CAPABILITIES 272 [S] 101 Capability list: 273 [S] VERSION 2 274 [S] IHAVE 275 [S] COMPRESS DEFLATE 276 [S] . 277 [C] COMPRESS DEFLATE 278 [S] 403 Unable to activate compression 280 Example of attempting to use an unsupported compression algorithm: 282 [C] CAPABILITIES 283 [S] 101 Capability list: 284 [S] VERSION 2 285 [S] IHAVE 286 [S] COMPRESS DEFLATE 287 [S] . 288 [C] COMPRESS X-SHRINK 289 [S] 503 Compression algorithm not supported 291 Examples of a server refusing to compress twice: 293 [C] CAPABILITIES 294 [S] 101 Capability list: 295 [S] VERSION 2 296 [S] IHAVE 297 [S] STARTTLS 298 [S] COMPRESS DEFLATE 299 [S] . 300 [C] STARTTLS 301 [S] 382 Continue with TLS negotiation 302 [TLS negotiation with compression occurs here] 303 [Following successful negotiation, all traffic is protected by TLS] 304 [C] CAPABILITIES 305 [S] 101 Capability list: 306 [S] VERSION 2 307 [S] IHAVE 308 [S] . 309 [C] COMPRESS DEFLATE 310 [S] 502 Compression already active via TLS 312 [C] CAPABILITIES 313 [S] 101 Capability list: 314 [S] VERSION 2 315 [S] IHAVE 316 [S] STARTTLS 317 [S] COMPRESS DEFLATE 318 [S] . 319 [C] COMPRESS DEFLATE 320 [S] 206 Compression active 321 [From this point on, all traffic is compresssed] 322 [C] CAPABILITIES 323 [S] 101 Capability list: 324 [S] VERSION 2 325 [S] IHAVE 326 [S] . 327 [C] STARTTLS 328 [S] 502 DEFLATE compression already active 329 Example of a server not advertising AUTHINFO mechanisms after 330 compression has been activated: 332 [C] CAPABILITIES 333 [S] 101 Capability list: 334 [S] VERSION 2 335 [S] READER 336 [S] AUTHINFO USER 337 [S] COMPRESS DEFLATE 338 [S] . 339 [C] COMPRESS DEFLATE 340 [S] 206 Compression active 341 [From this point on, all traffic is compresssed] 342 [C] CAPABILITIES 343 [S] 101 Capability list: 344 [S] VERSION 2 345 [S] READER 346 [S] AUTHINFO 347 [S] . 349 3. Compression Efficiency 351 This section is informative, not normative. 353 NNTP poses some unusual problems for a compression layer. 355 Upstream traffic is fairly simple. Most NNTP clients send the same 356 few commands again and again, so any compression algorithm that can 357 exploit repetition works efficiently. The article posting and 358 transfer commands (e.g., POST, IHAVE, and TAKETHIS [RFC4644]) are 359 exceptions; clients that send many article posting or transfer 360 commands may want to surround large multi-line data blocks with 361 flushes in the same way as is recommended for servers later in this 362 section. 364 Downstream traffic has the unusual property that several kinds of 365 data are sent, confusing all dictionary-based compression algorithms. 367 One type is NNTP simple responses and NNTP multi-line responses not 368 related to article header/body retrieval (e.g, CAPABILITIES, GROUP, 369 LISTGROUP, LAST, NEXT, STAT, DATE, NEWNEWS, NEWGROUPS, LIST, CHECK 370 [RFC4644], etc). These are highly compressible; zlib using its least 371 CPU-intensive setting compresses typical responses to 25-40% of their 372 original size. 374 Another type is article headers (as retrieved via the HEAD, HDR, 375 OVER, or ARTICLE commands). These are equally compressible, and 376 benefit from using the same dictionary as the NNTP responses. 378 A third type is article body text (as retrieved via the BODY or 379 ARTICLE commands). Text is usually fairly short and includes much 380 ASCII, so the same compression dictionary will do a good job here, 381 too. When multiple messages in the same thread are read at the same 382 time, quoted lines, etc. can often be compressed almost to zero. 384 Finally, attachments (non-text article bodies retrieved via the BODY 385 and ARTICLE commands) are transmitted in encoded form, usually Base64 386 [RFC4648], UUencode [IEEE.1003-2.1992], or yEnc [yEnc]. 388 When attachments are retrieved, DEFLATE may be able to compress them, 389 but the format of the attachment's encoding is usually not NNTP-like, 390 so the dictionary built while compressing NNTP does not help. The 391 compressor has to adapt its dictionary from NNTP to the attachment's 392 encoding format, and then back. 394 When attachments are retrieved in Base64 or UUencode form, these 395 encodings add another problem. 8-bit compression algorithms such as 396 DEFLATE work well on 8-bit file formats, however both Base64 and 397 UUencode transform a file into something resembling 6-bit bytes, 398 hiding most of the 8-bit file format from the compressor. 400 When using the zlib library (see [RFC1951]), the functions 401 deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to 402 implement this extension. The windowBits value must be in the range 403 -8 to -15 for deflateInit2(), or else it will use the wrong format. 404 The windowBits value should be -15 for inflateInit2(), or else it 405 will not be able to decompress a stream with a larger window size. 406 deflateParams() can be used to improve compression rate and resource 407 use. The Z_FULL_FLUSH argument to deflate() can be used to clear the 408 dictionary (the receiving peer does not need to do anything). 410 A server can improve downstream compression if it hints to the 411 compressor that the data type is about to change strongly, e.g., by 412 sending a Z_FULL_FLUSH at the start and end of large non-text multi- 413 line data blocks (before and after 'content-lines' in the definition 414 of 'multi-line-data-block' in [RFC3977] Section 9.8). Small multi- 415 line data blocks are best left alone. A possible boundary is 5kB. 417 4. Augmented BNF Syntax for the COMPRESS Extension 419 This section describes the syntax of the COMPRESS extension using 420 ABNF [RFC7405] [RFC5234]. It extends the syntax in Section 9 of 421 [RFC3977], and non-terminals not defined in this document are defined 422 there. The [RFC3977] ABNF should be imported first before attempting 423 to validate these rules. 425 4.1. Commands 427 This syntax extends the non-terminal "command", which represents an 428 NNTP command. 430 command =/ compress-command 432 compress-command = "COMPRESS" WS algorithm 434 4.2. Capability entries 436 This syntax extends the non-terminal "capability-entry", which 437 represents a capability that may be advertised by the server. 439 capability-entry =/ compress-capability 441 compress-capability = "COMPRESS" 1*(WS algorithm) 443 4.3. General Non-terminals 445 algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive 446 alg-char = UPPER / DIGIT / "-" / "_" 448 5. Summary of Response Codes 450 This section contains a list of each new response code defined in 451 this document and indicates whether it is multi-line, which commands 452 can generate it, what arguments it has, and what its meaning is. 454 Response code 206 455 Generated by: COMPRESS 456 Meaning: Compression layer activated 458 6. Security Considerations 460 TODO 462 7. IANA Considerations 464 7.1. NNTP Compression Algorithm Registry 466 The NNTP Compression Algorithm registry will be maintained by IANA. 467 The registry will be available at . 470 The purpose of this registry is not only to ensure uniqueness of 471 values used to name NNTP compression algorithms, but also to provide 472 a definitive reference to technical specifications detailing each 473 NNTP compression algorithm available for use on the Internet. 475 There is no naming convention for NNTP compression algorithms; any 476 name that conforms to the syntax of a NNTP compression algorithm name 477 can be registered. 479 The procedure detailed in Section 7.1.1 is to be used for 480 registration of a value naming a specific individual mechanism. 482 Comments may be included in the registry as discussed in 483 Section 7.1.2 and may be changed as discussed in Section 7.1.3. 485 7.1.1. Algorithm Name Registration Procedure 487 IANA will register new NNTP compression algorithm names on a First 488 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 489 the right to reject obviously bogus registration requests, but will 490 perform no review of claims made in the registration form. 492 Registration of an NNTP compression algorithm is requested by filling 493 in the following template and sending it via electronic mail to IANA 494 at : 496 Subject: Registration of NNTP compression algorithm X 498 NNTP compression algorithm name: 500 Security considerations: 502 Published specification (recommended): 504 Contact for further information: 506 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 508 Owner/Change controller: 510 Note: (Any other information that the author deems relevant may be 511 added here.) 513 While this registration procedure does not require expert review, 514 authors of NNTP compression algorithms are encouraged to seek 515 community review and comment whenever that is feasible. Authors may 516 seek community review by posting a specification of their proposed 517 mechanism as an Internet-Draft. NNTP compression algorithms intended 518 for widespread use should be standardized through the normal IETF 519 process, when appropriate. 521 7.1.2. Comments on Algorithm Registrations 523 Comments on a registered NNTP compression algorithm should first be 524 sent to the "owner" of the algorithm and/or to the mailing list. 527 Submitters of comments may, after a reasonable attempt to contact the 528 owner, request IANA to attach their comment to the NNTP compression 529 algorithm registration itself by sending mail to . At 530 IANA's sole discretion, IANA may attach the comment to the NNTP 531 compression algorithm's registration. 533 7.1.3. Change Control 535 Once an NNTP compression algorithm registration has been published by 536 IANA, the author may request a change to its definition. The change 537 request follows the same procedure as the registration request. 539 The owner of an NNTP compression algorithm may pass responsibility 540 for the algorithm to another person or agency by informing IANA; this 541 can be done without discussion or review. 543 The IESG may reassign responsibility for an NNTP compression 544 algorithm. The most common case of this will be to enable changes to 545 be made to algorithms where the author of the registration has died, 546 has moved out of contact, or is otherwise unable to make changes that 547 are important to the community. 549 NNTP compression algorithm registrations may not be deleted; 550 algorithms that are no longer believed appropriate for use can be 551 declared OBSOLETE by a change to their "intended usage" field; such 552 algorithms will be clearly marked in the lists published by IANA. 554 The IESG is considered to be the owner of all NNTP compression 555 algorithms that are on the IETF standards track. 557 7.2. Registration of the DEFLATE Compression Algorithm 559 This section gives a formal definition of the DEFLATE compression 560 algorithm as required by Section 7.1.1 for the IANA registry. 562 NNTP compression algorithm name: DEFLATE 564 Security considerations: See Section 6 of this document 566 Published specification: This document 568 Contact for further information: Author of this document 569 Intended usage: COMMON 571 Owner/Change controller: IESG . 573 Note: This algorithm is mandatory to implement 575 7.3. Registration of the NNTP COMPRESS Extension 577 This section gives a formal definition of the COMPRESS extension as 578 required by Section 3.3.3 of [RFC3977] for the IANA registry. 580 o The COMPRESS extension allows an NNTP connection to be effectively 581 and efficiently compressed. 583 o The capability label for this extension is "COMPRESS", whose 584 arguments list the available compression algorithms. 586 o This extension defines one new command, COMPRESS, whose behavior, 587 arguments, and responses are defined in Section 2.2. 589 o This extension does not associate any new responses with pre- 590 existing NNTP commands. 592 o This extension does affect the overall behavior of both server and 593 client, in that after successful use of the COMPRESS command, all 594 communication is transmitted in a compressed format. 596 o This extension does not affect the maximum length of commands or 597 initial response lines. 599 o This extension does not alter pipelining, but the COMPRESS command 600 cannot be pipelined. 602 o Use of this extension does alter the capabilities list; once the 603 COMPRESS command has been used successfully, the COMPRESS 604 capability can no longer be advertised by CAPABILITIES. 605 Additionally, the STARTTLS and MODE-READER capabilities MUST NOT 606 be advertised after successful execution of the COMPRESS command. 608 o This extension does not cause any pre-existing command to produce 609 a 401, 480, or 483 response. 611 o This extension is unaffected by any use of the MODE READER 612 command, however the MODE READER command MUST NOT be used in the 613 same session following a successful execution of the COMPRESS 614 command. 616 o The STARTTLS command MUST NOT be used in the same session 617 following a successful execution of the COMPRESS command. 619 o Published Specification: This document. 621 o Contact for Further Information: Author of this document. 623 o Change Controller: IESG . 625 8. References 627 8.1. Normative References 629 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 630 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 631 . 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 635 RFC2119, March 1997, 636 . 638 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 639 3977, DOI 10.17487/RFC3977, October 2006, 640 . 642 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 643 Transport Layer Security (TLS) with Network News Transfer 644 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 645 2006, . 647 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 648 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 649 DOI 10.17487/RFC5226, May 2008, 650 . 652 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 653 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 654 RFC5234, January 2008, 655 . 657 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 658 7405, DOI 10.17487/RFC7405, December 2014, 659 . 661 8.2. Informative References 663 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 664 Security Conference, 2012. 666 [IEEE.1003-2.1992] 667 Institute of Electrical and Electronics Engineers, 668 "Information Technology - Portable Operating System 669 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", 670 IEEE Standard 1003.2, 1992. 672 [MNP] Held, G., "The Complete Modem Reference", Second Edition, 673 Wiley Professional Computing, May 1994. 675 [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 676 RFC 1962, DOI 10.17487/RFC1962, June 1996, 677 . 679 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 680 Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 681 2004, . 683 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 684 Authentication and Security Layer (SASL)", RFC 4422, DOI 685 10.17487/RFC4422, June 2006, 686 . 688 [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer 689 Protocol (NNTP) Extension for Authentication", RFC 4643, 690 DOI 10.17487/RFC4643, October 2006, 691 . 693 [RFC4644] Vinocur, J. and K. Murchison, "Network News Transfer 694 Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, 695 DOI 10.17487/RFC4644, October 2006, 696 . 698 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 699 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 700 . 702 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 703 DOI 10.17487/RFC4978, August 2007, 704 . 706 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 707 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 708 RFC5246, August 2008, 709 . 711 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 712 Known Attacks on Transport Layer Security (TLS) and 713 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 714 February 2015, . 716 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 717 "Recommendations for Secure Use of Transport Layer 718 Security (TLS) and Datagram Transport Layer Security 719 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 720 2015, . 722 [V42bis] International Telecommunications Union, "Data compression 723 procedures for data circuit-terminating equipment (DCE) 724 using error correction procedures", ITU-T Recommendation 725 V.42bis, January 1990. 727 [yEnc] Helbing, J., "yEnc - Efficient encoding for Usenet and 728 eMail", March 2002, 729 . 731 Appendix A. Acknowledgements 733 This document draws heavily on ideas in [RFC4978] by Arnt Gulbrandsen 734 and a large portion of this text was borrowed from that 735 specification. 737 The author would like to thank the following individuals for 738 contributing their ideas and support for writing this specification: 739 Russ Allbery, Michael Baeuerle, and Julien ELIE, 741 Appendix B. Document History (to be removed by RFC Editor before 742 publication) 744 B.1. Changes since -01 746 o Switched to using 206 response code when compression has been 747 activated. 749 o Added text stating that TLS-level compression is susceptible to 750 CRIME attack and current BCP is to disable it. 752 o Added text stating that AUTHINFO shouldn't be advertised or used 753 after COMPRESS to prevent possible CRIME attack (with example). 755 o Added text stating that a windowBits value of -15 should be used 756 for inflateInit2(). 758 o Minor editorial changes. 760 B.2. Changes since -00 762 o Made DEFLATE the mandatory to implement compression algorithm. 764 o Removed the requirement that clients/servers implementing COMPRESS 765 also implement TLS compression. 767 o Added an example of a client trying to use an unsupported 768 compression algorithm. 770 o Rewrote Compression Efficiency (Section 3) as follows: 772 * Included a sample listing of which NNTP commands produce which 773 type of data to be compressed. 775 * Removed discussion of attachments in binary form and 776 incompressible file formats. 778 * Mentioned UUencode and yEnc encoding of attachments. 780 o Added IANA registry of NNTP compression algorithms. 782 o Miscellaneous editorial changes submitted by Julien Elie. 784 Appendix C. Issues to be addressed 786 o Should we restrict the ABNF for compression algorithms? We 787 currently use 'token' but that allows for UTF-8 chars and case- 788 insensitivity. 790 Author's Address 792 Kenneth Murchison 793 Carnegie Mellon University 794 5000 Forbes Avenue 795 Pittsburgh, PA 15213 796 US 798 Phone: +1 412 268 1982 799 Email: murch@andrew.cmu.edu