TLS Working Group T. Fossati Internet-Draft Nokia Updates: 5246, 6347 (if approved) N. Mavrogiannopoulos Intended status: Standards Track RedHat Expires: September 4, 2018 March 03, 2018 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 http://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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Fossati & MavrogiannopouExpires September 4, 2018 [Page 1] Internet-Draft Record Header Extensions for DTLS March 2018 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 2. Length Redefined . . . . . . . . . . . . . . . . . . . . . . 2 3. Record Header Extension . . . . . . . . . . . . . . . . . . . 3 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 4 3.4. Use with Connection ID . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Fossati & MavrogiannopouExpires September 4, 2018 [Page 2] Internet-Draft Record Header Extensions for DTLS March 2018 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: o 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; o Type is a fixed length (4-bits) field that defines the way Value has to be interpreted; o 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; o Value is the record header extension itself. Fossati & MavrogiannopouExpires September 4, 2018 [Page 3] Internet-Draft Record Header Extensions for DTLS March 2018 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: o Type: 0x0 (i.e., CID record header extension); o Value: the CID itself A DTLS 1.2 record carrying a CID "AB" would be formatted as in Figure 2: o E=1 o Type=0x0 Fossati & MavrogiannopouExpires September 4, 2018 [Page 4] Internet-Draft Record Header Extensions for DTLS March 2018 o Length=0x002 o 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. Fossati & MavrogiannopouExpires September 4, 2018 [Page 5] Internet-Draft Record Header Extensions for DTLS March 2018 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 [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-22 (work in progress), November 2017. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-25 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Fossati & MavrogiannopouExpires September 4, 2018 [Page 6] Internet-Draft Record Header Extensions for DTLS March 2018 8.2. Informative References [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, "The Datagram Transport Layer Security (DTLS) Connection Identifier", draft-ietf-tls-dtls-connection-id-00 (work in progress), December 2017. Authors' Addresses Thomas Fossati Nokia Email: thomas.fossati@nokia.com Nikos Mavrogiannopoulos RedHat Email: nmav@redhat.com Fossati & MavrogiannopouExpires September 4, 2018 [Page 7]