Skip to main content

Appendix A. Discussion of Changes to RFC 4507

RFC 4507 [RFC4507] defines a mechanism to resume a TLS session without maintaining server side state by specifying an encrypted ticket that is maintained on the client. The client presents this ticket to the server in a SessionTicket hello extension. The encoding in RFC 4507 used the XDR style encoding specified in TLS [RFC4346].

An error in the encoding caused the specification to differ from deployed implementations. At the time of this writing there are no known implementations that follow the encoding specified in RFC 4507. This update to RFC 4507 aligns the document with these currently deployed implementations.

Erroneous encoding in RFC 4507 resulted in two length fields; one for the extension contents and one for the ticket itself. Hence, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to RFC 4507:

     00 23          Ticket Extension type 35
     01 02          Length of extension contents
     01 00          Length of ticket
     FF FF .. ..    Actual ticket

The update proposed in this document reflects what implementations actually encode, namely it removes the redundant length field. So, for a ticket that is 256 bytes long and begins with the hex value FF FF, the encoding of the extension would be as follows according to this update:

     00 23          Extension type 35
     01 00          Length of extension contents (ticket)
     FF FF .. ..    Actual ticket

A server implemented according to RFC 4507 receiving a ticket extension from a client conforming to this document would interpret the first two bytes of the ticket as the length of this ticket. This will result in either an inconsistent length field or in the processing of a ticket missing the first two bytes. In the first case, the server should reject the request based on a malformed length. In the second case, the server should reject the ticket based on a malformed ticket, incorrect key version, or failed decryption. A server implementation based on this update receiving an RFC 4507 extension would interpret the first length field as the length of the ticket and include the second two length bytes as the first bytes in the ticket, resulting in the ticket being rejected based on a malformed ticket, incorrect key version, or failed decryption.

Note that the encoding of an empty SessionTicket extension was ambiguous in RFC 4507. An RFC 4507 implementation may have encoded it as:

     00 23      Extension type 35
     00 02      Length of extension contents
     00 00      Length of ticket

or it may have encoded it the same way as this update:

     00 23      Extension type 35
     00 00      Length of extension contents

A server wishing to support RFC 4507 clients should respond to an empty SessionTicket extension encoded the same way as it received it.

A server implementation can construct tickets such that it can detect an RFC 4507 implementation, if one existed, by including a cookie at the beginning of the tickets that can be differentiated from a valid length. For example, if an implementation constructed tickets to start with the hex values FF FF, then it could determine where the ticket begins and determine the length correctly from the type of length fields present.

This document makes a few additional changes to RFC 4507 listed below.

  • Clarifying that the server can allow session resumption using a ticket without issuing a new ticket in Section 3.1.

  • Clarifying that the lifetime is relative to when the ticket is received in section 3.3.

  • Clarifying that the NewSessionTicket handshake message is included in the hash generated for the Finished messages in Section 3.3.

  • Clarifying the interaction with TLS Session ID in Section 3.4.

  • Recommending the use of SHA-256 for the integrity protection of the ticket in Section 4.

  • Clarifying that additional data can be included in the StatePlaintext structure in Section 4.