idnits 2.17.1 draft-friend-tls-lzs-compression-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 584. -- Found old boilerplate from RFC 3978, Section 5.5 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 606. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 569), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2004) is 7259 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) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Friend 2 Internet-Draft Hifn 3 June 4, 2004 4 Expires: December 4, 2004 6 Transport Layer Security Protocol Compression Using LZS 7 draft-friend-tls-lzs-compression-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This memo provides information for the Internet community. It does 15 not specify an Internet standard of any kind. Distribution of this 16 memo is unlimited. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on December 4, 2004. 35 It is intended that a future version of this draft be submitted to 36 the IESG for publication as an Informational RFC. Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 The Transport Layer Security (TLS) protocol (RFC 2246) includes 43 features to negotiate selection of a lossless data compression method 44 as part of the TLS Handshake Protocol and to then apply the algorithm 45 associated with the selected method as part of the TLS Record 46 Protocol. TLS defines one standard compression method which 47 specifies that data exchanged via the record protocol will not be 48 compressed. This document describes an additional compression method 49 associated with the Lempel-Ziv-Stac (LZS) lossless data compression 50 algorithm for use with TLS. This document also defines the 51 application of the LZS algorithm to the TLS Record Protocol. 53 Conventions Used In This Document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 General. . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Licensing. . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3 Specification of Requirements. . . . . . . . . . . . . . 4 65 2. Compression Methods . . . . . . . . . . . . . . . . . . . . 4 66 2.1 LZS CompresionMethod . . . . . . . . . . . . . . . . . . 5 67 2.2 Security Issues with Single History Compression. . . . . 5 68 3. LZS Compression . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1 Background of LZS Compression . . . . . . . . . . . . . 5 70 3.2 LZS Compression History and Record Processing . . . . . 6 71 3.3 LZS Compressed Record Format . . . . . . . . . . . . . . 7 72 3.4 TLSComp Header Format . . . . . . . . . . . . . . . . . 7 73 3.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.5 LZS Compression Encoding Format . . . . . . . . . . . . 8 75 3.6 Padding . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4. Sending Compressed Records . . . . . . . . . . . . . . . . . 9 77 4.1 Transmitter Process . . . . . . . . . . . . . . . . . . 9 78 4.2 Receiver Process . . . . . . . . . . . . . . . . . . . . 10 79 4.3 Anti-Expansion Mechanism . . . . . . . . . . . . . . . . 10 80 5. Internationalization Considerations . . . . . . . . . . . . 11 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 86 Intellectual Property and Copyright Statements . . . . . . . 17 88 1. Introduction 90 1.1 General 92 The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes 93 features to negotiate selection of a lossless data compression method 94 as part of the TLS Handshake Protocol and to then apply the algorithm 95 associated with the selected method as part of the TLS Record 96 Protocol. TLS defines one standard compression method, 97 CompressionMethod.null, which specifies that data exchanged via the 98 record protocol will not be compressed. While this single 99 compression method helps ensure that TLS implementations are 100 interoperable, the lack of additional standard compression methods 101 has limited the ability of implementers to develop interoperable 102 implementations that include data compression. 104 TLS is used extensively to secure client-server connections on the 105 World Wide Web. While these connections can often be characterized 106 as short-lived and exchanging relatively small amounts of data, TLS 107 is also being used in environments where connections can be 108 long-lived and the amount of data exchanged can extend into thousands 109 or millions of octets. For example, TLS is now increasingly being 110 used as an alternative VPN connection. Compression services have 111 long been associated with IPSec and PPTP VPN connections, so 112 extending compression services to TLS VPN connections preserves the 113 user experience for any VPN connection. Compression within TLS is 114 one way to help reduce the bandwidth and latency requirements 115 associated with exchanging large amounts of data while preserving the 116 security services provided by TLS. 118 This document describes an additional compression method associated 119 with a lossless data compression algorithm for use with TLS. This 120 document specifies the application of Lempel-Ziv-Stac (LZS) 121 compression, a lossless compression algorithm, to TLS record 122 payloads. This specification also assumes a thorough understanding 123 of the TLS protocol [2]. 125 1.2 Specification of Requirements 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC-2119 [1]. 131 2. Compression Methods 133 As described in section 6 of RFC 2246 [2], TLS is a stateful 134 protocol. Compression methods used with TLS can be either stateful 135 (the compressor maintains its state through all compressed records) 136 or stateless (the compressor compresses each record independently), 137 but there seems to be little known benefit in using a stateless 138 compression method within TLS. The LZS compression method described 139 in this document is stateful. 141 Compression algorithms can occasionally expand, rather than compress, 142 input data. The worst case expansion factor of the LZS compression 143 method is only 12.5%. Thus, TLS records of 15K bytes can never 144 exceed the expansion limits described in section 6.2.2 of RFC 2246 145 [2]. If TLS records of 16K bytes expand to greater than 17K bytes, 146 then the uncompressed version of the TLS record must be transmitted, 147 as described below. 149 2.1 LZS CompressionMethod 151 The LZS CompressionMethod is a 16-bit index, and is negotiated as 152 described in RFC2246 [2] and RFC3749 [3]. The LZS CompressionMethod 153 is stored in the TLS Record Layer connection state as described in 154 RFC2246 [2]. 156 IANA has assigned as compression method identifier for applying 157 LZS compression to TLS record payloads. 159 2.2 Security Issues with Compression Histories 161 Sharing compression histories between more than one TLS session may 162 potentially cause information leakage between the TLS sessions, as 163 pathological compressed data can potentially reference data prior to 164 the beginning of the current record. LZS implementations guard 165 against this situation. However, to avoid this potential threat 166 from occurring, implementations that support TLS compression MUST use 167 separate compression histories for each TLS session. This is not a 168 limitation of LZS compression, but is an artifact for any 169 compression algorithm. 171 Furthermore, the LZS compression history (as well as any compression 172 history) contains plaintext. Specifically, the LZS history contains 173 the last 2K bytes of plaintext of the TLS session. Thus, when the 174 TLS session terminates, the implementation SHOULD treat the history 175 as it does any plaintext (e.g. free memory, overwrite contents, etc.). 177 3. LZS Compression 179 3.1 Background of LZS Compression 181 Starting with a sliding window compression history, similar to LZ1 182 [8], a new, enhanced compression algorithm identified as LZS was 183 developed. The LZS algorithm is a general-purpose lossless 184 compression algorithm for use with a wide variety of data types. 185 It's encoding method is very efficient, providing compression for 186 strings as short as two octets in length. 188 The LZS algorithm uses a sliding window of 2,048 bytes. During 189 compression, redundant sequences of data are replaced with tokens 190 that represent those sequences. During decompression, the original 191 sequences are substituted for the tokens in such a way that the 192 original data is exactly recovered. LZS differs from lossy 193 compression algorithms, such as those often used for video 194 compression, that do not exactly reproduce the original data. 195 The details of LZS compression can be found in section 3.5 below. 197 3.2 LZS Compression History and Record Processing 199 This standard specifies "stateful" compression, that is, maintaining 200 the compression history between records within a particular TLS 201 compression session. Within each separate compression history, the 202 LZS CompressionMethod has the ability to maintain compression 203 history information when compressing and decompressing record 204 payloads. Stateful compression provides a higher compression ratio 205 to be achieved on the data stream as compared to stateless 206 compression (resetting the compression history between every record), 207 particularly for small records. 209 Stateful compression requires both a reliable link and sequenced 210 record delivery, to ensure all records can be decompressed in the 211 same order they were compressed. Since TLS and lower-layer 212 protocols provide reliable, sequenced record delivery, compression 213 history information MAY be maintained and exploited when using the 214 LZS CompressionMethod. 216 Furthermore, there MUST be a separate LZS compression history 217 associated with each open TLS session. This not only provides 218 enhanced security (no potential information leakage between sessions 219 via a shared compression history), but also enables superior 220 compression ratio (bit bandwidth on the connection) across all open 221 TLS sessions with compression. A shared history would require 222 resetting the compression (and decompression) history when switching 223 between TLS sessions, and a single history implementation would 224 require resetting the compression (and decompression) history 225 between each record. 227 The sender MUST reset the compression history prior to compressing 228 the first TLS record of a TLS session after TLS handshake completes. 229 It is advantageous for the sender to maintain the compression history 230 for all subsequent records processed during the TLS session. This 231 results in the greatest compression ratio for a given data set. In 232 either case, this compression history MUST NOT be used for any other 233 open TLS session, in order to ensure privacy between TLS sessions. 235 The sender MUST "flush" the compressor each time it transmits a 236 compressed record. Flushing means that all data going into the 237 compressor is included in the output, i.e., no data is retained in 238 the hope of achieving better compression. Flushing ensures that 239 each compressed record payload can be decompressed completely. 240 Flushing is necessary to prevent a record's data from spilling over 241 into a later record. This is important to synchronize compressed 242 data with the authenticated and encrypted data in a TLS record. 243 Flushing is handled automatically in most LZS implementations. 245 When the TLS session terminates, the implementation SHOULD dispose of 246 the memory resources associated with the related TLS compression 247 history. That is, the compression history SHOULD be handled as the 248 TLS key material is handled. 250 The LZS CompressionMethod also features "decompressing" uncompressed 251 data in order to maintain the history in the case that the 252 "compressed" data actually expanded. The LZS CompressionMethod record 253 format facilitates identifying whether records contain compressed or 254 uncompressed data. The LZS decoding process accommodates decompressing 255 either compressed or uncompressed data. 257 3.3 LZS Compressed Record Format 259 Prior to compression, the uncompressed data (TLSPlaintext.fragment) 260 comprises a plaintext TLS record. After compression, the compressed 261 data (TLSCompressed.fragment) comprises a 8-bit TLSComp header 262 followed by the compressed (or uncompressed) data. 264 3.4. TLSComp Header Format 266 The one-octet header has the following structure: 268 0 269 0 1 2 3 4 5 6 7 270 +-+-+-+-+-+-+-+-+ 271 | Flags | 272 | | 273 +-+-+-+-+-+-+-+-+ 275 3.4.1 Flags 277 The format of the 8-bit Flags TLSComp field is as follows: 279 0 1 2 3 4 5 6 7 280 +-----+-----+-----+-----+-----+-----+-----+-----+ 281 | Res | Res | Res | Res | Res | Res | RST | C/U | 282 +-----+-----+-----+-----+-----+-----+-----+-----+ 284 Res - Reserved 286 Reserved for future use. MUST be set to zero. MUST be ignored 287 by the receiving node. 289 RST - Reset Compression History 291 The RST bit is used to inform the decompressing peer that 292 the compression history in this TLS session was reset prior 293 to the data contained in this TLS record being compressed. When 294 the RST bit is set to "1" a compression history reset is 295 performed, when RST is set to "0", a compression history reset is 296 not performed. 298 This bit MUST be set to a value of "1" for the first 299 compressed TLS transmitted record of a TLS session. This bit 300 may also be used by the transmitter for other exception cases 301 when the compression history must be reset. 303 C/U - Compressed/Uncompressed Bit 305 The C/U indicates whether the data field contains compressed or 306 uncompressed data. A value of 1 indicates compressed data 307 (often referred to as a compressed record), and a value of 0 308 indicates uncompressed data (or an uncompressed record). 310 3.5 LZS Compression Encoding Format 312 The LZS compression method, encoding format, and application examples 313 are described in RFC 1967 [6], RFC 1974 [5], and RFC 2395[4]. 315 Some implementations of LZS allow the sending compressor to select 316 from among several options to provide varying compression ratios, 317 processing speeds, and memory requirements. Other implementations of LZS 318 provide optimal compression ratio at byte per clock speeds. 320 The receiving LZS decompressor automatically adjusts to the settings 321 selected by the sender. Also, receiving LZS decompressors will update 322 the decompression history with uncompressed data. This facilitates 323 never obtaining less than 1:1 compression ratio (never transmit with 324 expanded data) in the session. 326 The input to the payload compression algorithm is TLSPlaintext data 327 destined to an active TLS session with compression negotiated. The 328 output of the algorithm is a new (and hopefully smaller) TLSCompressed 329 record. The output payload contains the input payload's data in 330 either compressed or uncompressed format. The input and output 331 payloads are each an integral number of bytes in length. 333 The output payload is always prepended with the TLSComp header. If 334 the uncompressed form is used, the output payload is identical to 335 the input payload, and the TLSComp header reflects uncompressed data. 337 If the compressed form is used, encoded as defined in ANSI X3.241 338 [7], and the TLSComp header reflects compressed data. The LZS 339 encoded format is repeated here for informational purposes ONLY. 341 := [*] 342 := 0 | 1 344 := (8-bit byte) 345 := 347 := 1 | (7-bit offset) 348 0 (11-bit offset) 349 := 110000000 350 := 1 | 0 352 := 353 00 = 2 1111 0110 = 14 354 01 = 3 1111 0111 = 15 355 10 = 4 1111 1000 = 16 356 1100 = 5 1111 1001 = 17 357 1101 = 6 1111 1010 = 18 358 1110 = 7 1111 1011 = 19 359 1111 0000 = 8 1111 1100 = 20 360 1111 0001 = 9 1111 1101 = 21 361 1111 0010 = 10 1111 1110 = 22 362 1111 0011 = 11 1111 1111 0000 = 23 363 1111 0100 = 12 1111 1111 0001 = 24 364 1111 0101 = 13 ... 366 3.6 Padding 368 A datagram payload compressed using LZS always ends with the last 369 compressed data byte (also known as the ), which is used 370 to disambiguate padding. This allows trailing bits as well as bytes 371 to be considered padding. 373 The size of a compressed payload MUST be in whole octet units. 375 4. Sending Compressed Datagrams 377 All TLS records processed with a TLS session state that includes LZS 378 compression are processed as follows. The reliable and efficient 379 transport of LZS compressed records in the TLS session depends on 380 the following processes. 382 4.1. Transmitter Process 384 The compression operation results in either compressed or 385 uncompressed data. When a TLS record is received, it is 386 assigned to a particular TLS context that includes the LZS 387 compression history buffer. It is processed according to 388 ANSI X3.241-1994 to form compressed data or used as is to form 389 uncompressed data. For the first record of the session, or for 390 exception conditions, the compression history MUST be cleared. In 391 performing the compression operation the compression history MUST 392 be updated when either a compressed record or uncompressed record 393 is produced. Uncompressed TLS records MAY be sent at any time. 394 Uncompressed TLS records MUST be sent if compression causes 395 enough expansion to cause the data compression TLS record size to 396 exceed the MTU defined in section 6.2.2 in RFC 2246. 397 The output of the compression operation is placed in the fragment 398 field of the TLSCompressed structure (TLSCompressed.fragment). 400 The TLSComp header byte is located just prior to the first byte 401 of the compressed TLS record in TLSCompressed.fragment. The C/U 402 bit in the TLSComp header is set according to whether the data 403 field contains compressed or uncompressed data. The RST bit in 404 the TLSComp header is set to "1" if the compression history was 405 reset prior to compressing the TLSplaintext.fragment that 406 comprises TLSCompressed.fragment. Uncompressed data MUST be 407 transmitted (and the C/U bit set to 0) if the "compressed" 408 (expanded) data exceeded 17K bytes. 410 4.2. Receiver Process 412 Prior to decompressing the first compressed TLS record in the TLS 413 session, the receiver MUST reset the decompression history. 414 Subsequent records are decompressed in the order received. The 415 receiver decompresses the Payload Data field according to the 416 encoding specified in section 3.5 above. 418 If the received datagram is not compressed, the receiver needs to 419 perform no decompression processing and the Payload Data field of the 420 datagram is ready for processing by the next protocol layer. 422 After a TLS record is received from the peer and decrypted, the 423 RST and C/U bits MUST be checked. 425 If the C/U bit is set to "1", the resulting compressed data block 426 MUST be decompressed according to section 3.5 above. 428 If the C/U bit is set to "0", the specified decompression history 429 MUST be updated with the received uncompressed data. 431 If the RST bit is set to "1", the receiving decompression history 432 MAY be reset to an initial state prior to decompressing the TLS 433 record. (However, due to the characteristics of the Hifn LZS 434 algorithm, a decompression history reset is not required). 435 After reset, any compressed or uncompressed data contained in the 436 record is processed. 438 4.3. Anti-Expansion Mechanism 440 During compression, there are two options on how to handle 441 records that expand: 443 1) Send the expanded data (as long as TLSCompressed.length is 444 17K or less) and maintain the history, thus allowing loss of 445 current bandwidth but preserving future bandwidth on the 446 link. 448 2) Send the uncompressed data and do not clear the compression 449 history; the decompressor will update its history, thus 450 conserving the current bandwidth and future bandwidth on the 451 link. 452 The second option is the preferred option, and SHOULD be implemented. 454 A third option: 456 3) Send the uncompressed data and clear the history, thus 457 conserving current bandwidth, but allowing possible loss of 458 future bandwidth on the link. 460 SHOULD NOT be implemented. 462 5. Internationalization Considerations 464 The compression method identifiers specified in this document are 465 machine-readable numbers. As such, issues of human 466 internationalization and localization are not introduced. 468 6. IANA Considerations 470 Section 2 of RFC3749 [3] describes a registry of compression method 471 identifiers to be maintained by the IANA and to be assigned within 472 three zones. 474 IANA is requested to assign an identifier for the LZS compression 475 method from the RFC2434 Specification Required IANA pool as 476 described in sections 2 and 5 of RFC3749 [3]. 478 The IANA-assigned compression method identifier for LZS is TBD 479 decimal (0xTBD). 481 7. Security Considerations 483 This document does not introduce any topics that alter the threat 484 model addressed by TLS. The security considerations described 485 throughout RFC 2246 [2] apply here as well. 487 However, combining compression with encryption can sometimes reveal 488 information that would not have been revealed without compression: 489 data that is the same length before compression might be a different 490 length after compression, so adversaries that observe the length of 491 the compressed data might be able to derive information about the 492 corresponding uncompressed data. Some symmetric encryption 493 ciphersuites do not hide the length of symmetrically encrypted data 494 at all. Others hide it to some extent, but still don't hide it 495 fully. For example, ciphersuites that use stream cipher encryption 496 without padding do not hide length at all; ciphersuites that use 497 Cipher Block Chaining (CBC) encryption with padding provide some 498 length hiding, depending on how the amount of padding is chosen. Use 499 of TLS compression SHOULD take into account that the length of 500 compressed data may leak more information than the length of the 501 original uncompressed data. 503 Another security issue to be aware of is that the LZS compression 504 history contains plaintext. In order to prevent any kind of 505 information leakage to outside the system, when a TLS session with 506 compression terminates, the implementation SHOULD treat the 507 compression history as it does plaintext, that is, care should be 508 taken not to reveal the compression history in any form, or use it 509 again. This is described both in sections 2.2 and 3.2 above. 511 This information leakage concept can be extended to the situation of 512 sharing a single compression history across more than one TLS 513 session, as addressed in section 2.2 above. 515 Other security issues are discussed in RFC3749 [3]. 517 8. Acknowledgements 519 The concepts described in this document were derived from RFC 1967 520 [6], RFC 1974 [5], RFC 2395 [4], and RFC3749 [3]. The author 521 acknowledges the contributions of Scott Hollenbeck, Douglas Whiting, 522 Russell Dietz, and the help from Steve Bellovin, Russ Housley, Eric 523 Rescorla. 525 Normative References 527 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 528 Levels", BCP 14, RFC 2119, March 1997. 530 [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 531 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 532 January 1999. 534 [3] Hollenbeck, S. " Transport Layer Security Protocol Compression 535 Methods", RFC3749, May 2004 537 Informative References 539 [4] Friend, R., IP Payload Compression Using LZS", RFC 2395, 540 December 1998. 542 [5] Friend, R., "PPP Stac LZS Compression Protocol", RFC 1974, August 1996. 544 [6] Friend, R., "PPP LZS-DCP Compression Protocol (LZS-DCP)", RFC 1967, 545 August 1996. 547 [7] American National Standards Institute, Inc., "Data 548 Compression Method for Information Systems," ANSI X3.241- 549 1994, August 1994. 551 [8] Lempel, A., and Ziv, J., "A Universal Algorithm for 552 Sequential Data Compression", IEEE Transactions On 553 Information Theory, Vol. IT-23, No. 3, September 1977. 555 Author's Address 557 Robert Friend 558 Hifn 559 5973 Avenida Encinas 560 Carlsbad, CA 92008 561 US 563 Email: rfriend@hifn.com 565 Full Copyright Statement 567 Copyright (C) The Internet Society (2004). This document is subject 568 to the rights, licenses and restrictions contained in BCP 78, and 569 except as set forth therein, the authors retain all their rights. 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 574 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 575 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 576 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 Intellectual Property 581 By submitting this Internet-Draft, I certify that any applicable 582 patent or other IPR claims of which I am aware have been disclosed, 583 and any of which I become aware will be disclosed, in accordance with 584 RFC 3668. 586 The IETF takes no position regarding the validity or scope of any 587 Intellectual Property Rights or other rights that might be claimed to 588 pertain to the implementation or use of the technology described in 589 this document or the extent to which any license under such rights 590 might or might not be available; nor does it represent that it has 591 made any independent effort to identify any such rights. Information 592 on the procedures with respect to rights in RFC documents can be 593 found in BCP 78 and BCP 79. 595 Copies of IPR disclosures made to the IETF Secretariat and any 596 assurances of licenses to be made available, or the result of an 597 attempt made to obtain a general license or permission for the use of 598 such proprietary rights by implementers or users of this 599 specification can be obtained from the IETF on-line IPR repository at 600 http://www.ietf.org/ipr. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights that may cover technology that may be required to implement 605 this standard. Please address the information to the IETF at ietf- 606 ipr@ietf.org. 608 Acknowledgement 610 Funding for the RFC Editor function is currently provided by the 611 Internet Society.