Re: I-D ACTION:draft-ietf-tls-rfc2246-bis-02.txt

Folks,

> This document specifies Version 1.0 of the Transport Layer Security
> (TLS) protocol. The TLS protocol provides communications privacy over
> the Internet. The protocol allows client/server applications to
> communicate in a way that is designed to prevent eavesdropping,
> tampering, or message forgery.

In case it wasn't totally clear, the 1.0 above is an editing error.
The version should be 1.1 throughout.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com

Note Well Statement

From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

---

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Hi All,

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
the ciphersuite.

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

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

    The compression algorithms with which I am familiar (which is admittedly a
very small set) all handle suppressing negative compression within the
compression stream itself.  In other words, the compressor has a way to mark a
packet as being uncompressed so that the decompressor does not attempt to
decompress it.  Thus, everything can still be sent through the decompressor
just based on the fact that compression has been negotiated.  However,...

    Even ignoring the fact that there are probably compression algorithms for
which the above is not true, I also like the idea of providing the capability
for designating specific records as not candidates for compression.  With at
least some algorithms, attempting compression on something which is not
compressible affects the compression state such that the overall compression
ratio achieved is lower than could be achieved if a method existed for
bypassing the compressor for stuff that is known not to be compressible. 
(Kind of a long sentence.  I hope it is coherent.  Its been a long week
already...)

John

Robert Friend wrote:
> 
> Hi All,
> 
> 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

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Robert Friend <rfriend <at> hifn.com> writes:
> 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.

I think the assumption was that for algorithms which had the potential
to expand the data this much you would have a "not-compressed" flag 
that would allow you to fail to compress any given record. This seems
far simpler than creating a new content type.

-Ekr

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Hi Eric,

Yes, there could be a flag, presumably in the payload.  Either way the
transmitter must write a field during record processing.  But at the
receiver it seems more simple to read a single field, rather than interpret
the flag in the payload differently depending on ciphersuite.

You probably know more about TLS implementations than I, is creating a
contentType a "big deal"?

BTW, 10-12% expansion on totally random data is not unreasonable.  It just
looks "large" when trying to compress large records.

Regards,
===================================================
Robert C. Friend
Technology Marketing
Hifn Inc. 
5973 Avenida Encinas, Carlsbad, CA 92008
(760) 827-4542 (voice)    (760) 827-4577 (FAX)
www.hifn.com
===================================================

-----Original Message-----
From: Eric Rescorla [mailto:ekr <at> rtfm.com]
Sent: Thursday, November 07, 2002 1:38 PM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Robert Friend <rfriend <at> hifn.com> writes:

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Robert Friend <rfriend <at> hifn.com> writes:
> Yes, there could be a flag, presumably in the payload.  Either way the
> transmitter must write a field during record processing.  But at the
> receiver it seems more simple to read a single field, rather than interpret
> the flag in the payload differently depending on ciphersuite.
The idea, I would think, would be that it would be handled entirely
by the compression algorithm. I.e. it would be treated as part of
the input to decompression.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Hi Eric,

You can say that, but in reality I believe it would be the protocol that
reads that payload's preamble and decides how to handle the payload.    That
is, it's software: you can call it "compression" software or "protocol"
software.

My point is that it requires special case that software to read the various
payload preambles based on the compression algorithm in the ciphersuire,
rather than using the already implemented software that reads the fixed
contentType.

Also, for hardware accelerators, the contentType would be preferred, I
believe.

Regards,
===================================================
Robert C. Friend
Technology Marketing
Hifn Inc. 
5973 Avenida Encinas, Carlsbad, CA 92008
(760) 827-4542 (voice)    (760) 827-4577 (FAX)
www.hifn.com
===================================================

-----Original Message-----
From: Eric Rescorla [mailto:ekr <at> rtfm.com]
Sent: Thursday, November 07, 2002 5:26 PM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-compression-03.txt

RE: I-D ACTION:draft-ietf-tls-compression-03.txt

Robert Friend <rfriend <at> hifn.com> writes:
> You can say that, but in reality I believe it would be the protocol that
> reads that payload's preamble and decides how to handle the payload.    That
> is, it's software: you can call it "compression" software or "protocol"
> software.
It's almost always software. However, it's an issue of modularity.

> My point is that it requires special case that software to read the various
> payload preambles based on the compression algorithm in the ciphersuire,
> rather than using the already implemented software that reads the fixed
> contentType.
I'm confused about your programming model. You're going to have some
dispatch table that calls the appropriate decompression routine based
on the entry in the cipher suite (recall that null is a possibility).
The first thing that routine does is read the (compression suite-dependent)
header, which may or may not include a "I didn't really compress" 
indicator. If that indicator is present, the decompression routine
just strips off the indicator and returns the rest of the text.

> Also, for hardware accelerators, the contentType would be preferred, I
> believe.
I don't see why this would be the case. And since it substantially
complicates the rest of the protocol, I don't think it's a particularly
good engineering tradeoff.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/

RE: I-D ACTION:draft-ietf-tls-compression-03.txt