Record Header Extensions for TLS and DTLS

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Both TLS (, ) and DTLS (, ) require the size of TLS record payloads to not exceed 2^14 bytes - plus a small amount that accounts for compression or AEAD expansion. This means that the first bit in the length field of the TLS record header is, in fact, unused. The proposal () is to shorten the length field to 15 bits and use the top bit (E) to signify the presence / absence of a &foo;.

Length counts the bytes of Payload and of all &foo;s that are added to this record (possibly none). In the reminder, the top bit is called the E-bit.

If the E-bit is asserted, then a &foo; is appended to the regular header with the following format:

Where: M(ore) has the same semantics as the E-bit in the regular header - i.e.: if it is asserted then another extension header follows this one; Type is a fixed length (4-bits) field that defines the way Value has to be interpreted; Length is the size of Value in bytes. It uses 11 bits, therefore allowing a theoretical maximum size of 2047 bytes for any &foo;; Value is the &foo; itself. The fact that Type only allows 16 &foo; is a precise design choice: the allocation pool size is severely constrained so to raise the entry bar for any new &foo;.

A &foo; is allowed only if it has been negotiated via a companion TLS extension. An endpoint MUST NOT send a &foo; that hasn't been successfully negotiated with the receiver. An endpoint that receives an unexpected &foo; MUST abort the session. &Foo;s MUST NOT be sent during the initial handshake phase.

A legacy endpoint that receives a &foo; will interpret it as an invalid length field (, ) and abort the session accordingly. Note that this is equivalent to the behaviour of an endpoint implementing this spec which receives a non-negotiated &foo;.

A plausible use of this mechanism is with the CID extension defined in . In that case, the companion &foo; could be defined as follows: Type: 0x0 (i.e., CID &foo;); Value: the CID itself A DTLS 1.2 record carrying a CID "AB" would be formatted as in : E=1 Type=0x0 Length=0x002 Value=0x4142

Note that, compared to all other possible ways to express presence/absence of a CID field within the constraints of the current header format (e.g., bumping the Version field, assigning new ContentType(s), using an invalid length), an ad hoc &foo; provides a cleaner approach that can be used with any TLS version at a reasonable cost - an overhead of 2 bytes per record.

An on-path active attacker could try and modify an existing &foo;, insert a new &foo; in an existing session, or alter the result of the negotiation in order to add or remove arbitrary &foo;s. Given the security properties of TLS, none of the above can be tried without being fatally noticed by the endpoints. A passive on-path attacker could potentially extrapolate useful knowledge about endpoints from the information encoded in a &foo; (see also ).

The extent and consequences of metadata leakage from endpoints to path when using a certain &foo; SHALL be assessed in the document that introduces this new &foo;. If needed, the document SHALL describe the relevant risk mitigations.

This document defines a new IANA registry that, for each new &foo;, shall provide its Type code-point.

TODO