[Docs] [txt|pdf] [Tracker] [Email] [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 7, 2012                                 March 6, 2012


     Datagram Transport Layer Security in Constrained Environments
                      draft-hartke-core-codtls-00

Abstract

   We consider some obstacles when it comes to implement Datagram
   Transport Layer Security (DTLS) in constrained environments, and
   present some ideas for a constrained version of DTLS that is friendly
   to constrained devices.

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 7, 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 7, 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 . . . . . . . . . 4
     3.1.  Smaller messages  . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Less state  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Shorter handshakes  . . . . . . . . . . . . . . . . . . . . 6
     3.4.  Fewer transmissions . . . . . . . . . . . . . . . . . . . . 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




































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


Internet-Draft              Constrained DTLS                  March 2012


1.  Introduction

   In Section 2, we consider some obstacles when it comes to implement
   Datagram Transport Layer Security (DTLS) [RFC6347] in constrained
   environments.

   In Section 3, we present some ideas for a constrained version of DTLS
   that is friendly to constrained devices by enabling small buffer
   sizes, reduced state and fewer and smaller messages -- at the cost of
   being constrained.


2.  Implementing DTLS in Constrained Environments

   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.  Network communication,
   especially wireless, also imposes constraints that need to be
   considered during protocol design, e.g. small bandwidth, variable
   delay and possibly high packet loss.  Moreover, frames at the link
   layer might be too small for the IPv6 minimum MTU of 1280 bytes and
   therefore require additional mapping mechanisms such as 6LoWPAN
   [RFC4944] for IEEE 802.15.4 wireless networks.

   As high loss rates are anticipated by design, application protocols
   usually try to avoid fragmentation at the network layer.  More often
   than not, the protocol overhead from securing the communication is
   not taken into consideration.  As an example, DTLS has a per-record
   overhead of 13 bytes 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 bytes, leading to an overall of 29
   bytes 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
   constrained devices as buffers must be large enough to hold all
   fragments for reassembly and losing a single fragment will cause the
   entire message flight to be retransmitted.

   (TODO: Because the frame size is so small, it is actually quite
   likely that records need to be fragmented and that records of the
   same message flight are transmitted in separate datagrams.  This
   means that message loss and reordering become increasingly probable.)

   (TODO: In DTLS, each retransmission is a new record with a new
   sequence number value.  This means that a sender cannot encrypt



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


Internet-Draft              Constrained DTLS                  March 2012


   plaintext in-place but must keep the plaintext in a separate buffer
   until the transmission succeeds or eventually times out.)

   (TODO: Six message flights for a full DTLS handshake (see Figure 1)
   are at least two too many.)

   (TODO: We expect that nodes communicate with the same small set of
   nodes over a very long time with low traffic.  However, nodes may not
   be able to keep even a small number of sessions open for extended
   periods of time.)

    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: Message flights for full handshake


3.  Constrained Datagram Transport Layer Security

3.1.  Smaller messages

   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.



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


Internet-Draft              Constrained DTLS                  March 2012


   o  Stateless header compression (cf. [RFC6282]):

      *  When AES-CCM [I-D.mcgrew-tls-aes-ccm] (a set of AEAD cipher
         suites) 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.

      *  Similarly, if the DTLS version is negotiated in the handshake,
         there is 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.

      *  DTLS records specify their length so multiple records can be
         transmitted in a single datagram.  When DTLS is used with UDP,
         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.

   o  Elliptic curve cryptography for small key sizes: "Smaller key
      sizes result in savings for power, memory, bandwidth, and
      computational cost that make ECC especially attractive for
      constrained environments."  [RFC4492]

3.2.  Less state

   o  The Finished message includes the hash of all handshake messages
      which, for this purpose, need to processed in the right order.  If
      this would not be required, handshake messages within a flight
      could be processed in any order, alleviating the need for large
      buffers to bring reordered messages back into order.  An
      alternative to the hash of the concatenation of all the Handshake
      structures might be to compute the hash of the pending connection
      state (i.e. the SecurityParameters structure, client and server
      write parameters, negotiated extensions, etc.).

   o  If entities use an out-of-band mechanism to exchange large blobs
      such as certificates (e.g., CoAP [I-D.ietf-core-coap]), then
      fragmentation could be removed altogether.

   o  (TODO: If the possibility of rehandshakes was constrained/removed,
      there would be no need for current and pending, read and write
      state.)





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


Internet-Draft              Constrained DTLS                  March 2012


   o  (TODO: 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  Client puzzles have been proposed as a mechanism for mitigating
      denial-of-service attacks.  Client puzzles could be used in DTLS
      to create a four-flight exchange similiar to the one in HIP DEX
      [I-D.moskowitz-hip-rg-dex] (shown in Figure 2).  The application
      to TLS has been shown [Usenix01].

   o  TLS False Start [I-D.bmoeller-tls-falsestart]: Achieves an
      improvement of one round-trip time for full handshakes if the
      client sends application data first and for abbreviated handshakes
      if the server sends application data first.

   o  TLS Snap Start [I-D.agl-tls-snapstart]: Eliminates the latency of
      handshakes when the client has prior knowledge about the server.
      This prior knowledge is not secret and may be obtained from third
      parties (e.g., a CoRE Resource Directory
      [I-D.shelby-core-resource-directory]) and cached for significant
      periods of time.


         Initiator                              Responder

                      I1:
                    -------------------------->
                                                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 2: Four-packet HIP DEX exchange







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


Internet-Draft              Constrained DTLS                  March 2012


3.4.  Fewer transmissions

   o  (TODO: Use CON/ACK/RST/NON so only lost messages need to
      retransmitted instead of the whole flight.)


4.  Security Considerations

   Security issues are discussed throughout this memo.


5.  IANA Considerations

   This memo includes no request to IANA.


6.  References

6.1.  Normative References

   [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

   [I-D.agl-tls-snapstart]
              Langley, A., "Transport Layer Security (TLS) Snap Start",
              draft-agl-tls-snapstart-00 (work in progress), June 2010.

   [I-D.bmoeller-tls-falsestart]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start",
              draft-bmoeller-tls-falsestart-00 (work in progress),
              June 2010.

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

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




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


Internet-Draft              Constrained DTLS                  March 2012


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

   [I-D.shelby-core-resource-directory]
              Krco, S. and Z. Shelby, "CoRE Resource Directory",
              draft-shelby-core-resource-directory-02 (work in
              progress), October 2011.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

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

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [Usenix01]
              Dean, D. and A. Stubblefield, "Using Client Puzzles to
              Protect TLS", 2001,
              <http://www.csl.sri.com/users/ddean/papers/usenix01b.pdf>.


Authors' Addresses

   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

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









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


Internet-Draft              Constrained DTLS                  March 2012


   Olaf Bergmann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

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










































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


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