Re: [TLS] About the contents of Record Layers

[[e-mail]]

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?


On Aug 1, 2010 10:42am, Juho Vähä-Herttua <[e-mail]> wrote:
> On 1.8.2010, at 18.08, JCA wrote:

> > 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?



> 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