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

Versions: 00 01 02 draft-hartke-dice-practical-issues

CoRE Working Group                                             K. Hartke
Internet-Draft                                               O. Bergmann
Intended status: Informational                   Universitaet Bremen TZI
Expires: September 14, 2012                               March 13, 2012

     Datagram Transport Layer Security in Constrained Environments


   We consider some obstacles in implementing Datagram Transport Layer
   Security (DTLS) in constrained environments, and present some ideas
   for a constrained version of DTLS that is friendly to constrained
   nodes and networks.

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 14, 2012.

Copyright Notice

   Copyright (c) 2012 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
   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.

Hartke & Bergmann      Expires September 14, 2012               [Page 1]

Internet-Draft              Constrained DTLS                  March 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Implementing DTLS in Constrained Environments  . . . . . . . .  3
   3.  Constrained Datagram Transport Layer Security  . . . . . . . .  5
     3.1.  Smaller messages . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Less state . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Shorter handshakes . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Fewer transmissions  . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Hartke & Bergmann      Expires September 14, 2012               [Page 2]

Internet-Draft              Constrained DTLS                  March 2012

1.  Introduction

   Nodes that take part in the "Internet of Things" often have strict
   limitations regarding their computational power, memory size (both,
   ROM and RAM), and power management [I-D.bormann-lwig-guidance].
   Network communication, especially wireless, also imposes constraints
   that need to be considered during protocol design, e.g. low bitrate,
   variable delay and possibly high packet loss.  Moreover, frames at
   the link layer might be much smaller than the IPv6 minimum MTU of
   1280 octets and therefore require additional mapping mechanisms such
   as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks, which in
   turn may exacerbate the limitations of the network: E.g., as high
   loss rates are anticipated by design, application protocols usually
   try to avoid fragmentation at the network layer.

   However, application protocols often delegate security mechanisms to
   transport layer security protocols.  More often than not, the
   protocol overhead from securing the communication is highly relevant
   to the overall performance of the systems.

   One protocol that has received significant attention recently for
   constrained node/network applications is Datagram Transport Layer
   Security (DTLS) [RFC6347].  DTLS is derived from and inherits some
   characteristics from TLS [RFC5246], which has not been designed with
   constrained nodes/networks in mind.

   The present document considers some obstacles in implementing DTLS in
   constrained environments, and presents some ideas for a constrained
   version of DTLS that is friendly to constrained nodes and networks.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Implementing DTLS in Constrained Environments

   As an example for the TLS traits that DTLS inherits (and
   exacerbates), DTLS has a per-record overhead of 13 octets for the
   record header.  AEAD ciphers such as AES-CCM [I-D.mcgrew-tls-aes-ccm]
   eat up additional space to carry the explicit nonce and the MAC.
   Thus, the cipher suite TLS_PSK_WITH_AES_128_CCM_8 suggested by CoAP
   [I-D.ietf-core-coap] for Pre-Shared Key mode requires 16 additional
   octets, leading to an overall overhead of 29 octets for each
   encrypted DTLS packet.

   Although DTLS offers fragmentation at the record layer and hence can
   get around IP fragmentation, packet loss still is a big problem for

Hartke & Bergmann      Expires September 14, 2012               [Page 3]

Internet-Draft              Constrained DTLS                  March 2012

   constrained nodes; buffers must be large enough to hold all fragments
   for reassembly and losing a single fragment will cause the entire
   DTLS message to be retransmitted.  This is very likely especially for
   messages at the handshake layer during key and certificate exchange
   as these will not fit within a single frame in most 6LoWPANs.

   Besides buffer space for packet reassembly at the receiver, a sender
   must provide extra buffer space for payload encoding.  In particular,
   the use of some AEAD ciphers requires inclusion of sequence numbers
   in the ciphertext calculation.  The sender therefore must keep the
   plaintext version of each message in a separate buffer and thus
   cannot encrypt it in place.

   Nodes with very constrained main memory also suffer from the complex
   DTLS handshake protocol.  Figure 1 shows the message flights required
   for a full DTLS handshake.  We envision that the acceptance of DTLS
   as security protocol for embedded devices would significantly
   increase if a faster setup procedure with a smaller number of
   handshake messages was defined.

    Client                                          Server
    ------                                          ------

    ClientHello             -------->                           Flight 1

                            <-------    HelloVerifyRequest      Flight 2

    ClientHello             -------->                           Flight 3

                                               ServerHello    \
                                              Certificate*     \
                                        ServerKeyExchange*      Flight 4
                                       CertificateRequest*     /
                            <--------      ServerHelloDone    /

    Certificate*                                              \
    ClientKeyExchange                                          \
    CertificateVerify*                                          Flight 5
    [ChangeCipherSpec]                                         /
    Finished                -------->                         /

                                        [ChangeCipherSpec]    \ Flight 6
                            <--------             Finished    /

        Figure 1: The six message flights of a full DTLS handshake

Hartke & Bergmann      Expires September 14, 2012               [Page 4]

Internet-Draft              Constrained DTLS                  March 2012

3.  Constrained Datagram Transport Layer Security

   This section presents a random collection of ideas for a constrained
   version of DTLS ("Constrained DTLS") that is friendly to constrained
   nodes by enabling small buffer sizes, reduced state and fewer and
   smaller messages -- at the cost of being constrained.

   The ideas fall into the following categories:

   Implementation guidance:  Implementation techniques for achieving
      light-weight implementations of DTLS, without affecting
      conformance to the relevant specifications or interoperability
      with other implementations.  This includes techniques for reducing
      complexity, memory footprint, or power usage.  The result may
      eventually be incorporated into [I-D.bormann-lwig-guidance].

   Stateless header compression:  DTLS records get compressed without
      explicitly building any compression context state.  This is done
      by using shorter forms to represent the same bits of information
      or relying on information that is already shared by client and
      server.  Existing DTLS implementations can continue to be used if
      a thin layer is added that handles compression/decompression.

   Protocol profile:  Use of DTLS in a particular way, for example, by
      changing MAYs into MUSTs or MUST NOTs, or by requiring or
      precluding certain extensions or cipher suites.  Existing DTLS
      implementations ought to continue to be used without change if
      they can be configured accordingly.

   Other:  Breaking changes.  New implementations are required that do
      not interoperate with implementations of DTLS.

3.1.  Smaller messages

   o  When AES-CCM [I-D.mcgrew-tls-aes-ccm] is used, the
      GenericAEADCipher.nonce_explicit field is set to the 16-bit epoch
      concatenated with the 48-bit sequence number.  This means the
      epoch and sequence number are included twice in each record.
      Stateless header compression could eliminate this redundancy.

   o  Since the DTLS version is negotiated in the handshake, there
      should be no need to specify the DTLS version in each and every
      record.  Stateless header compression could eliminate the DTLS
      version field where it is implicitly clear.

   o  DTLS records specify their length so multiple records can be
      transmitted in a single datagram.  When DTLS is used with UDP
      (which preserves the message boundaries of all sent messages),

Hartke & Bergmann      Expires September 14, 2012               [Page 5]

Internet-Draft              Constrained DTLS                  March 2012

      stateless header compression could eliminate the length field of
      the last record in a datagram.

   o  Use of self-delimiting numeric values [RFC6256] instead of fixed-
      size numeric values.  For example, the 16-bit epoch is either 0 or
      1 in most cases.

   o  Use of a bit field instead of multiple type fields to indicate
      which handshake messages are present in a datagram.

3.2.  Less state

   o  The handshake messages within a flight can be processed in any
      order: they essentially all just mutate the connection state
      without any interdependence.  The resulting state is not needed
      until all messages have been received.  However, the TLS Finished
      message includes the hash of all handshake messages which, for
      this purpose, need to be processed in the right order for the hash
      to be correct.  If this was not required, the need for large
      buffers to queue reordered messages for future handling could be

      An alternative to the hash of the concatenation of all the
      Handshake structures might be to compute the hash of the current
      and the pending connection state (security parameters, client and
      server write parameters, negotiated extensions, etc.).

   o  The reassembly of fragmented handshake messages requires large
      buffers, because buffer space is not only needed to reassemble the
      next expected message, but also reordered fragments of following
      messages.  If entities are required to use an out-of-band
      mechanism to exchange large blobs, then the fragmentation of
      messages could be removed altogether.

      For example, the TLS Cached Information Extension
      [I-D.ietf-tls-cached-info] allows to omit the exchange of fairly
      static information, such as the server certificate, if this
      information is already available.

   o  TLS defines four logical connection states: the current read and
      write states, and the pending read and write states.  Records are
      processed under the current states; pending states are needed
      during a (re-)handshake until ChangeCipherSpec makes the pending
      states current.

      The maintenance of a pool of connection states can lead to
      considerable complexity in an implementation.  To reduce
      complexity, implementations can choose to not support

Hartke & Bergmann      Expires September 14, 2012               [Page 6]

Internet-Draft              Constrained DTLS                  March 2012

      rehandshakes.  This allows the implementation to logically keep
      only the following connection states: the read and write states of
      epoch 0 (which specifies that no encryption, compression, or MAC
      is used), and the read and writes states of epoch 1.  These four
      states can be implemented in a very compact way.

   o  In DTLS, each retransmission is a new record with a new sequence
      number value.  If the sequence number if part of the nonce, this
      means that a sender cannot encrypt plaintext in-place but must
      keep the plaintext in a separate buffer until the transmission
      succeeds or eventually times out.

      If retransmission would not use a new sequence number, plaintext
      could be encrypted in-place without the need for a second buffer.

3.3.  Shorter handshakes

   o  A DTLS handshake has two additional flights when compared to TLS,
      resulting from the addition of a stateless cookie exchange.  This
      exchange is designed to prevent certain denial-of-service attacks:
      consumption of excessive server resources cause by the
      transmission of a series of handshake initiation requests, and use
      of the server as an amplifier by sending connection initiation
      messages with a forged source of the victim.

      If the cipher suite permits that the server remains stateless
      after sending ServerHello..ServerHelloDone, and
      ServerHello..ServerHelloDone fits in one datagram, then a full
      handshake could perhaps be shortened to four flights (see
      Figure 2).

Hartke & Bergmann      Expires September 14, 2012               [Page 7]

Internet-Draft              Constrained DTLS                  March 2012

    Client                                          Server
    ------                                          ------

    ClientHello             -------->                           Flight 1

                                        HelloVerifyRequest    \
                                               ServerHello      Flight 2
                            <--------      ServerHelloDone    /
                                        (remain stateless)

    ClientHello                                               \
    "ServerHello"                                              \
    ClientKeyExchange                                           Flight 3
    [ChangeCipherSpec]                                         /
    Finished                -------->                         /

                                        [ChangeCipherSpec]    \ Flight 4
                            <--------             Finished    /

     Figure 2: Artist's impression of a four-flight DTLS PSK handshake

   o  As an alternative, client puzzles could be used as a mechanism for
      mitigating denial-of-service attacks, resulting in a four-flight
      exchange similar to the one in HIP DEX [I-D.moskowitz-hip-rg-dex]
      (shown in Figure 3).  The application of client puzzles to TLS has
      been shown [Usenix01].  However, in the case the client is a
      constrained node, client puzzles may be too challenging.

         Initiator                              Responder

                                                select precomputed R1
                      R1: puzzle, PK
      solve puzzle                              remain stateless
      PK Encrypt x
                    I2: solution, PK, ECR(DH,secret x), mac
                                                check puzzle
                                                check mac
                                                PK Encrypt y
                              R2: PK, ECR(DH,secret y), mac
      check mac

                Figure 3: The four-packet HIP DEX exchange

Hartke & Bergmann      Expires September 14, 2012               [Page 8]

Internet-Draft              Constrained DTLS                  March 2012

3.4.  Fewer transmissions

   o  DTLS allows multiple messages of the same ContentType to be
      coalesced into a single record.  As a matter of implementation
      quality, implementations should coalesce as many messages of the
      same ContentType into a single record as possible.  Similarly,
      implementations should not fragment a message if the record fits
      in a single datagram.

   o  In DTLS, when a datagram carrying one part of a flight is lost,
      the whole flight needs to be retransmitted, possibly requiring the
      retransmission of the whole previous flight.

      A thin reliability layer such as the one provided by CoAP
      [I-D.ietf-core-coap] could be used, such that only the messages
      that are lost would need to be retransmitted instead of all
      messages of an entire flight.

4.  Security Considerations

   Beyond stateless header compression and profiling, changes to the
   TLS/DTLS protocol need to be performed extremely carefully.  No
   analysis has been done in the present version of this draft.

5.  IANA Considerations

   This draft includes no request to IANA.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

6.2.  Informative References

              Bormann, C., "Guidance for Light-Weight Implementations of

Hartke & Bergmann      Expires September 14, 2012               [Page 9]

Internet-Draft              Constrained DTLS                  March 2012

              the Internet Protocol Suite",
              draft-bormann-lwig-guidance-01 (work in progress),
              January 2012.

              Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), October 2011.

              Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension",
              draft-ietf-tls-cached-info-11 (work in progress),
              December 2011.

              McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS",
              draft-mcgrew-tls-aes-ccm-03 (work in progress),
              February 2012.

              Moskowitz, R., "HIP Diet EXchange (DEX)",
              draft-moskowitz-hip-rg-dex-05 (work in progress),
              March 2011.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
              Values in Protocols", RFC 6256, May 2011.

              Dean, D. and A. Stubblefield, "Using Client Puzzles to
              Protect TLS", 2001,

Hartke & Bergmann      Expires September 14, 2012              [Page 10]

Internet-Draft              Constrained DTLS                  March 2012

Authors' Addresses

   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359

   Phone: +49-421-218-63905
   Fax:   +49-421-218-7000
   Email: hartke@tzi.org

   Olaf Bergmann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359

   Phone: +49-421-218-63904
   Fax:   +49-421-218-7000
   Email: bergmann@tzi.org

Hartke & Bergmann      Expires September 14, 2012              [Page 11]

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