Skip to main content

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