Transport Layer Security Protocol Compression Methods
draft-ietf-tls-compression-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the Yes position for Ned Freed |
2004-02-09
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-02-09
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-02-09
|
07 | Amy Vezza | IESG has approved the document |
2004-02-09
|
07 | Amy Vezza | Closed "Approve" ballot |
2004-02-09
|
07 | Ned Freed | [Ballot Position Update] Position for Ned Freed has been changed to Yes from No Objection by Ned Freed |
2004-02-09
|
07 | Ned Freed | [Ballot Position Update] Position for Ned Freed has been changed to No Objection from Discuss by Ned Freed |
2004-01-29
|
07 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
2004-01-16
|
07 | (System) | New version available: draft-ietf-tls-compression-07.txt |
2004-01-08
|
07 | Amy Vezza | Removed from agenda for telechat - 2004-01-08 by Amy Vezza |
2004-01-08
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-01-08
|
07 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-01-08
|
07 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-01-08
|
07 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2004-01-08
|
07 | Bert Wijnen | [Ballot comment] Is it not confusing to have both sect 3 and sect 9? Both discussing IPR considerartions!? |
2004-01-08
|
07 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
2004-01-08
|
07 | Thomas Narten | [Ballot discuss] Section 2: Having ranges for stuff produced by the TLS WG and another range for other WGs doesn't make technical sense. Plus, the … [Ballot discuss] Section 2: Having ranges for stuff produced by the TLS WG and another range for other WGs doesn't make technical sense. Plus, the TLS WG will eventually go away. Better: > 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are > reserved for future standardization efforts of the IETF TLS > working group. better: reserved for IETF Standards Track protocols. > 2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are > reserved for assignment by the IANA for specifications developed > outside the TLS working group. Assignments from this range of > values MUST be made by the IANA and MUST be associated with a > formal reference that describes the compression method. what is a formal reference? Better: 2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are reserved for assignment for non-Standards Track methods. > 3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are > reserved for private use. I would assert that this range is too big. You don't need a lot of space for private use, and wouldn't it be better to assign numbers and use document protocols (ala 2 above?). Also, once it's given private use status, you can't easily reclaim it for other uses. > 5. IANA Considerations > > Section 2 of this document describes a registry of compression method > identifiers to be maintained by the IANA, including assignment of an > identifier for the ZLIB compression method. Identifier values from > the range reserved for future standardization efforts of the TLS > working group MUST be assigned according to the "Standards Action" > policy described in RFC 2434 [3]. Values from the range reserved for > private use MUST be used according to the "Private Use" policy > described in RFC 2434. Values from the general IANA pool MUST be > assigned according to the "IETF Consensus" policy described in RFC > 2434. better: 5. IANA Considerations Section 2 of this document describes a registry of compression method identifiers to be maintained by the IANA, including assignment of an identifier for the ZLIB compression method. Identifier values from the range 0-63 decimal are assigned via Standards Action [RFC2434]; Values from the range 64-192 (decimal) are assigned via Specification Required [RFC2434]; Identifier values from 193-255 [xxx though I think this should be smaller] are reserved for Private Use [RFC 2434]. Section 3 (IPR) appropriate? (doesn't follow standard conventions). |
2004-01-08
|
07 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten |
2004-01-08
|
07 | Jon Peterson | [Ballot comment] A recompile with would be nice. |
2004-01-08
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-01-08
|
07 | Allison Mankin | [Ballot comment] Clearly written. "the compressor maintains it's state" -> its In the IANA Considerations: per Harald's comment on the TLS WG lifetime, could make … [Ballot comment] Clearly written. "the compressor maintains it's state" -> its In the IANA Considerations: per Harald's comment on the TLS WG lifetime, could make this something like "TLS WG or its successor as designated by the Security Area of the IETF". |
2004-01-08
|
07 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Yes by Allison Mankin |
2004-01-08
|
07 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Undefined by Allison Mankin |
2004-01-08
|
07 | Allison Mankin | [Ballot comment] Good document. "the compressor maintains it's state" -> its In the IANA Considerations: the TLS WG is not eternal, so it would be … [Ballot comment] Good document. "the compressor maintains it's state" -> its In the IANA Considerations: the TLS WG is not eternal, so it would be good to say something like "TLS WG or whatever successor is designated by the Security Area of the IETF". |
2004-01-07
|
07 | Allison Mankin | [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin |
2004-01-07
|
07 | Harald Alvestrand | [Ballot comment] I think Ned's DISCUSS is important, and warrants a new I-D. Minor nit: In section 2 bullet 1, the TLS WG assumes that … [Ballot comment] I think Ned's DISCUSS is important, and warrants a new I-D. Minor nit: In section 2 bullet 1, the TLS WG assumes that it will live forever. The paragraph should stop after "future standardization efforts". Similarly in bullet 2. |
2004-01-07
|
07 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-01-07
|
07 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-01-07
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2004-01-06
|
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2003-12-20
|
07 | Ned Freed | [Ballot discuss] First of all, it is important to realize that RFC 1950 and RFC 1951 specify two things: (1) A compression scheme and corresponding … [Ballot discuss] First of all, it is important to realize that RFC 1950 and RFC 1951 specify two things: (1) A compression scheme and corresponding format called DEFLATE (1951) and (2) A general wrapper format for compressed data called ZLIB (1950). I believe most compression applications simply use the DEFLATE format and don't bother with the extra wrapper and most of our specifications that do this refer to deflate and RFC 1951 rather than zlib and RFC 1950. This document doesn't follow this approach. Rather, it repeatedly calls the compression scheme ZLIB and refers to both of the RFCs. Does this mean this specification actually uses the zlib wrapper? I suspect the answer is no, and if that's indeed the case, the document needs to be clarified in this regard. I suggest referring to the scheme as DEFLATE and removing the reference to RFC 1950 entirely. If, on the other hand, the intent really is to use the zlib wrapper, then the specification is incomplete in that ZLIB allows for multiple compression algorithms, checksumming, and so forth. These various settings would need to be specified in order to have interoperable ZLIB implementations. Next, the security considerations seem incomplete to me. For one thing, compression algorithms are complex beasts and prone to implementation errors in general and buffer overrun problems in particular. And this is especially egregious in the present case because the most popular implementation of deflate/zlib has a history of these sorts of problems. I therefore think this deserves to be called out in the security considerations. Another issue is the ability to construct rogue data which, when uncompresses, expands to enormous size. A comment about the interaction of compression and integrity protection in TLS needs to be made and the 2^14 limit TLS places on the size of the resulting compressed data should be mentioned as a means of ameliorating this sort of attack. Finally, while the specifics of how session resumption and compression schemes interact probably can be determined by slogging through RFC 2246, a direct statement as to whether or not session resumption clears the compression state would be a nice addition to this document. |
2003-12-20
|
07 | Ned Freed | [Ballot Position Update] New position, Discuss, has been recorded for by Ned Freed |
2003-12-19
|
07 | Steven Bellovin | [Ballot Position Update] New position, Yes, has been recorded for Steven Bellovin |
2003-12-19
|
07 | Steven Bellovin | Ballot has been issued by Steve Bellovin |
2003-12-19
|
07 | Steven Bellovin | Created "Approve" ballot |
2003-12-19
|
07 | (System) | Ballot writeup text was added |
2003-12-19
|
07 | (System) | Last call text was added |
2003-12-19
|
07 | (System) | Ballot approval text was added |
2003-12-19
|
07 | Steven Bellovin | Placed on agenda for telechat - 2004-01-08 by Steve Bellovin |
2003-12-19
|
07 | Steven Bellovin | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Steve Bellovin |
2003-12-19
|
07 | Steven Bellovin | State Change Notice email list have been change to , from |
2003-12-19
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2003-12-05
|
07 | Amy Vezza | Last call sent |
2003-12-05
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2003-11-24
|
07 | Steven Bellovin | State Changes to Last Call Requested from Publication Requested by Steve Bellovin |
2003-11-24
|
07 | Steven Bellovin | Requested an IPR section conformant to current guidelines. |
2003-11-24
|
07 | Steven Bellovin | State Changes to Publication Requested from AD is watching by Steve Bellovin |
2003-11-21
|
06 | (System) | New version available: draft-ietf-tls-compression-06.txt |
2003-05-28
|
05 | (System) | New version available: draft-ietf-tls-compression-05.txt |
2002-12-02
|
04 | (System) | New version available: draft-ietf-tls-compression-04.txt |
2002-11-04
|
07 | Steven Bellovin | Draft Added by Bellovin, Steve |
2002-10-23
|
03 | (System) | New version available: draft-ietf-tls-compression-03.txt |
2002-10-07
|
02 | (System) | New version available: draft-ietf-tls-compression-02.txt |
2002-09-20
|
01 | (System) | New version available: draft-ietf-tls-compression-01.txt |
2002-09-05
|
00 | (System) | New version available: draft-ietf-tls-compression-00.txt |