RE: I-D ACTION:draft-ietf-tls-compression-03.txt
Robert Friend <rfriend <at> hifn.com>
2002-11-07 20:03:21 GMT
I would like to make a small suggestion to consider.
Unlike the other algorithms defined in the ciphersuite, compression may not
be applied to all packets. Specifically, there will be situations where the
compression transform will exceed the maximum record size, such as a 16KB
packet that "compresses" (expands) to something larger than 17KB, or a
hypothetical 10KB packet that "compresses" (expands) to 12.5KB. Both of
these scenarios break RFC2246, section 6.2.2. In this case, the plaintext
MUST be protected by the ciphersuite but *without* compression enabled.
There is another situation where compression SHOULD be disabled. When the
implementation knows that the plaintext is pre-compressed, such as HTTP
content-coding is set to a compressed format. In this scenario, it would be
beneficial to disable compression for those certain records within the
protected TLS link, while still affording all the records TLS protection of
So, what I am suggesting is that an additional contentType identifier be
defined in this specification. Currently there are four contentTypes
defined in TLS: handshake, alert, change cipher spec, and application data.
I would propose defining a "compressed application data" contentType in this
I-D. So, compressed-protected packets contain this new contentType, and
packets that are protected, but not compressed, contain the standard
"application data" contentType. This allows the receiver to immediately
know whether the protected record is compressed or not.
Yes, it is possible to require the payload to identify itself, but that is
more complicated for the standards body to define, since every compression