[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
              editor.org/info/rfc5246>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.








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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/