Record Header Extensions for DTLS
draft-fossati-tls-ext-header-01

Abstract

This document proposes a mechanism to extend the record header in DTLS. To that aim, the DTLS header is modified as follows: the length field is trimmed to 15 bits, and the length's top bit is given the "record header extension indicator" semantics, allowing a sender to signal that one or more record header extensions have been added to this record. We define the generic format of a record header extension and the general rules associated with its handling. Any details regarding syntax, semantics and negotiation of a specific record header extension, are left to future documents.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 4, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Length Redefined
• 3. Record Header Extension
• 3.1. Format
• 3.2. Negotiation
• 3.3. Backwards Compatibility
• 3.4. Use with Connection ID
• 4. Security Considerations
• 5. Privacy Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

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 [RFC2119].

2. Length Redefined

DTLS ([RFC6347], [I-D.ietf-tls-dtls13]) requires the size of 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 DTLS record header is, in fact, unused.

The proposal (Figure 1) is to shorten the length field to 15 bits and use the top bit (E) to signify the presence / absence of a record header extension.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|  ContentType  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        ProtocolVersion        |             epoch             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        sequence_number                        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |E|            length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~             (zero or more) Extension Header(s)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload (including optional MAC and padding)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Length redefined

Length counts the bytes of Payload and of all record header extensions that are added to this record (possibly none).

In the reminder, the top bit is called the E-bit.

3. Record Header Extension

3.1. Format

If the E-bit is asserted, then a record header extension is appended to the regular header with the following format:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------+
|M| Type  |       Length        | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------+

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 record header extension;
• Value is the record header extension itself.

The fact that Type only allows 16 record header extension is a precise design choice: the allocation pool size is severely constrained so to raise the entry bar for any new record header extension.

3.2. Negotiation

A record header extension is allowed only if it has been negotiated via a companion DTLS extension.

An endpoint MUST NOT send a record header extension that hasn't been successfully negotiated with the receiver.

An endpoint that receives an unexpected record header extension MUST abort the session.

Record header extensions MUST NOT be sent during the initial handshake phase.

3.3. Backwards Compatibility

A legacy endpoint that receives a record header extension will interpret it as an invalid length field ([RFC6347], [I-D.ietf-tls-dtls13]) and abort the session accordingly.

Note that this is equivalent to the behaviour of an endpoint implementing this spec which receives a non-negotiated record header extension.

3.4. Use with Connection ID

A plausible use of this mechanism is with the CID extension defined in [I-D.ietf-tls-dtls-connection-id].

In that case, the companion record header extension could be defined as follows:

• Type: 0x0 (i.e., CID record header extension);
• Value: the CID itself

A DTLS 1.2 record carrying a CID "AB" would be formatted as in Figure 2:

• E=1
• Type=0x0
• Length=0x002
• Value=0x4142

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+
|  ContentType  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Version            |             Epoch             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |1|            Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|  0x0  |       0x002         |            0x4142             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload (including optional MAC and padding)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: CID header example

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 record header extension provides a cleaner approach that can be used with any TLS version at a reasonable cost - an overhead of 2 bytes per record.

4. Security Considerations

An on-path active attacker could try and modify an existing record header extension, insert a new record header extension in an existing session, or alter the result of the negotiation in order to add or remove arbitrary record header extensions. Given the security properties of DTLS, 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 record header extension (see also Section 5).

5. Privacy Considerations

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

6. IANA Considerations

This document defines a new IANA registry that, for each new record header extension, shall provide its Type code-point.

7. Acknowledgements

Thanks to Adam Langley and Yoav Nir for comments and discussions that have helped shaping this document.

This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI). This support does not imply endorsement.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses