Subject: [TLS] About the contents of Record Layers

From: JCA <[email-masked]>
Date: Sun, 1 Aug 2010 09:08:09 -0600

Does the TLS 1.* specs allow to send a Record Layer with an empty
body? That is, a Record Layer containing only the protocol ID, version
and length fields? I don't see why would anyone want to do that but,
is it legal?

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 1 Aug 2010 11:35:29 -0500

With the current record types that are available, it is not legal:

1. All cipher suites except TLS_NULL_WITH_NULL_NULL add at least one byte of
overhead to each record.
2. Only application data records are allowed to be empty.
3. Application data records must never be sent with TLS_NULL_WITH_NULL_NULL.

However, in practice, zero-length records (at the plaintext or ciphertext
level) aren't useful thing to check in an implementation. Usually an
implementation will want to check ciphertext records' lengths against the
expected per-record-IV length + expected authentication tag/MAC length
instead.

Regards,
Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of JCA
> Sent: Sunday, August 01, 2010 10:08 AM
> To: [email-masked]
> Subject: [TLS] About the contents of Record Layers
> 
> Does the TLS 1.* specs allow to send a Record Layer with an empty body?
That is,
> a Record Layer containing only the protocol ID, version and length fields?
I don't
> see why would anyone want to do that but, is it legal?
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 1 Aug 2010 19:42:49 +0300

> and length fields? I don't see why would anyone want to do that but,

The specification seems to be quite clear about this, in TLS 1.0:

6.2.  Record Layer

   The TLS record layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

...and clarified in TLS 1.2...

   Implementations MUST NOT send zero-length fragments of Handshake,
   Alert, or ChangeCipherSpec content types.  Zero-length fragments of
   Application data MAY be sent as they are potentially useful as a
   traffic analysis countermeasure.

So in case of application data they can be sent, in reality I would do serious testing with existing implementations to see how they behave. If they are TLS 1.2 compliant and negotiate a TLS 1.2 connection they should all accept the empty records though.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 1 Aug 2010 19:47:00 +0300

> 3. Application data records must never be sent with TLS_NULL_WITH_NULL_NULL.

Good point with not allowing application data records with null cipher suites, so it doesn't really work.

Juho

---

From: [email-masked]
Date: Sun, 01 Aug 2010 17:00:51 +0000

My thanks Juho and Brian for your feedback. On a similar topic, my  
understanding is that a Record Layer can encapsulate several protocol  
messages, all of them belonging to the same protocol. This makes sense for  
Alert and Handshake protocol messages, for they contain all the information  
necessary to find out where protocol messages of those types end (which may  
happen only after many Record Layers have been received.) The same applies  
to ChangeCipherSpec messages, albeit I do not understand why one would want  
to encapsulate more than one such message in a Record Layer. Now what about  
Application data messages? I believe that as far as TLS is concerned these  
messages are just blobs of data; ie it's beyond the scope of TLS to know  
where they end. Thus, is it not the case that a Record Layer can contain  
one, and only one, Application data message? Obviously, the application can  
spread its data over many Record Layers, but when TLS receives a Record  
Layer with Application data it automatically knows that the whole of the  
Record Layer's payload is a single, structure-less (as far as TLS is  
concerned) string of bytes. Is this a correct assessment?

> So in case of application data they can be sent, in reality I would do  
> serious testing with existing implementations to see how they behave. If  
> they are TLS 1.2 compliant and negotiate a TLS 1.2 connection they should  
> all accept the empty records though.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 01 Aug 2010 11:09:37 -0700

2^(1/2):

You are correct that application data is just a blob that is passed on to
the application.  It is not processed by the TLS "layer" at all, other
than to decrypt it and verify its integrity.

Multiple handshake messages can be combined into one record, or a single
handshake message may span multiple records.  Handling this can be tricky.

Usually only one alert message will be sent over a connection in each
direction, but you have to be prepared to receive several, even in the
same record.  You should also be prepared to receive just the AlertLevel
byte in one record and the AlertDescription in another.

Change cipher spec messages only make sense at specific places in the
handshake message sequence, so you should never receive more than one in
a single record.  If you do receive more than one, it is an error.

Mike

[email-masked] wrote:
> messages, all of them belonging to the same protocol. This makes sense 
> for Alert and Handshake protocol messages, for they contain all the 
> information necessary to find out where protocol messages of those types 
> end (which may happen only after many Record Layers have been received.) 
> The same applies to ChangeCipherSpec messages, albeit I do not 
> understand why one would want to encapsulate more than one such message 
> in a Record Layer. Now what about Application data messages? I believe 
> that as far as TLS is concerned these messages are just blobs of data; 
> i.e. it's beyond the scope of TLS to know where they end. Thus, is it 
> not the case that a Record Layer can contain one, and only one, 
> Application data message? Obviously, the application can spread its data 
> over many Record Layers, but when TLS receives a Record Layer with 
> Application data it automatically knows that the whole of the Record 
> Layer's payload is a single, structure-less (as far as TLS is concerned) 
> string of bytes. Is this a correct assessment?