Subject: [TLS] Still more on Record Layers

From: JCA <[email-masked]>
Date: Mon, 2 Aug 2010 09:37:20 -0600

I am somewhat confused about the meaning of the length field in a
Record Layer. I believe that when the protocol messages, MAC and
padding (if any) are encrypted in a Record Layer, the length field
contains the length in bytes of this encrypted blob (otherwise I guess
it would be difficult to determine when a Record Layer being received
ends.) Now it would seem that with the exception of the
TLS_NULL_WITH_NULL_NULL cipher suite (which seems to be equivalent to
what happens during the initial handshake, where no cryptographic
cipher suite has been agreed on yet) if you have encryption you
necessarily have MAC, but you can have MAC without encryption. What
does the Record Layer length field contain in the latter case? Is it
the length of the (unencrypted) encapsulated protocol messages alone,
or the sum of this plus the length of the MAC?

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 2 Aug 2010 11:29:18 -0500

JCA wrote:
> If you have encryption you necessarily have MAC,

Or an authentication tag, for AEAD cipher suites

> but you can have MAC without encryption. What does the Record
> Layer length field contain in the latter case? Is it the length of the
> (unencrypted) encapsulated protocol messages alone, or the sum
> of this plus the length of the MAC?

It is treated exactly the same as the stream cipher (e.g. RC4) case, and
that is why it is described in the same section. Think of NULL encryption as
a stream cipher that always produces zeros.

I think many of your questions can be answered by examining the code of one
of the many existing open-source implementations such as GnuTLS or OpenSSL.
(The code of NSS's libssl is perhaps less clear in how it deals with the
record layer as it is kind of obfuscated with optimizations, and also
contains some subtle bugs in how it checks the length of the record against
the various limits that the specification imposes.)

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Mon, 02 Aug 2010 17:15:45 -0500

On 08/02/2010 10:37 AM, JCA wrote:
> contains the length in bytes of this encrypted blob

I don't think that's how it works. The record layer length "doesn't 
care" whether the records are encrypted or not.

> (otherwise I guess
> ends.)

Yeah, we could have some fun parsing challenges if the type, version, 
and length fields were modified by the connection state. Probably an 
especially fun challenge for the attackers.

> Now it would seem that with the exception of the
> necessarily have MAC, but you can have MAC without encryption.

Here's the record layer:
http://tools.ietf.org/html/rfc5246#page-19
> struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           opaque fragment[TLSPlaintext.length];
>       } TLSPlaintext;

IMHO, it's a little misleading to call it TLSPlaintext since after the 
CCS record it's what we usually call "ciphertext".

It's not perfectly "opaque" to the record layer either since "The Record 
Protocol takes messages to be transmitted, fragments the data into 
manageable blocks, optionally compresses the data, applies a MAC, 
encrypts, and transmits the result."

But, IIRC, the length field represents the length of the record on the 
wire, so it doesn't know about how the data has been slice-n-diced. This 
makes it possible to always find the start of the next record by looking 
at t-he length field without knowing anything about the specific 
ContentType.

> What
> does the Record Layer length field contain in the latter case?

The length of the "opaque fragment" in every case.

> Is it

It's the count of bytes between (exclusive) this record's length field 
and the next record's content type, regardless of either content type.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 02 Aug 2010 16:05:54 -0700

> CCS record it's what we usually call "ciphertext".

You missed this on page 21:

6.2.3.  Record Payload Protection

       The encryption and MAC functions translate a TLSCompressed
       structure into a TLSCiphertext.  The decryption functions reverse
       the process.  The MAC of the record also includes a sequence
       number so that missing, extra, or repeated messages are
       detectable.

       struct {
           ContentType type;
           ProtocolVersion version;
           uint16 length;
           select (SecurityParameters.cipher_type) {
               case stream: GenericStreamCipher;
               case block:  GenericBlockCipher;
               case aead:   GenericAEADCipher;
           } fragment;
       } TLSCiphertext;

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 02 Aug 2010 18:39:53 -0500

> You missed this on page 21:

Yeah that makes more sense. I was confused.

> the process.

Still, I think it would be helpful if the spec said "TLSCiphertext is 
the record layer structure that is actually sent on the wire even if the 
cipher suite is TLS_NULL_WITH_NULL_NULL and it looks exactly like 
TLSPlaintext". I can't a direct statement like that in the spec.

- Marsh