[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: January 17, 2013                                  July 16, 2012


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

Abstract

   This draft considers some obstacles in implementing Datagram
   Transport Layer Security (DTLS) in constrained environments, and
   presents 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 January 17, 2013.

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 January 17, 2013                [Page 1]


Internet-Draft              Constrained DTLS                   July 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Potential Problems and Possible Solutions  . . . . . . . . . .  4
     2.1.  Handshake Message Fragmentation  . . . . . . . . . . . . .  4
     2.2.  Timer Values . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Connection Initiation  . . . . . . . . . . . . . . . . . .  7
     2.4.  Connection Closure . . . . . . . . . . . . . . . . . . . .  9
     2.5.  Application Data Fragmentation . . . . . . . . . . . . . .  9
     2.6.  Data size  . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.7.  Code size  . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Stateless Header Compression . . . . . . . . . . . . . . . . . 12
     3.1.  Records  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Handshake Messages . . . . . . . . . . . . . . . . . . . . 13
   4.  RESTful DTLS Handshake . . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Templates . . . . . . . . . . . . . . . . . . . . . . 20
     A.1.  secp256r1  . . . . . . . . . . . . . . . . . . . . . . . . 20
     A.2.  secp384r1  . . . . . . . . . . . . . . . . . . . . . . . . 21
     A.3.  secp521r1  . . . . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23






















Hartke & Bergmann       Expires January 17, 2013                [Page 2]


Internet-Draft              Constrained DTLS                   July 2012


1.  Introduction

1.1.  Background

   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.ietf-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 bytes and therefore require additional mapping mechanisms such
   as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks
   [IEEE.802-15-4], 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].  Although DTLS has not been
   designed with constrained nodes/networks in mind, it is thought to be
   usable in such environments [SOS12].  Still, there are a few
   challenges when it comes to implement DTLS.

1.2.  Overview

   The present document considers some obstacles in implementing DTLS in
   constrained environments, and presents a few ideas to make DTLS more
   friendly to constrained nodes and networks.

   The ideas generally fall into one of 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.ietf-lwig-guidance].






Hartke & Bergmann       Expires January 17, 2013                [Page 3]


Internet-Draft              Constrained DTLS                   July 2012


   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.

   Stateless header compression:  Compression of DTLS records 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 the client and
      server.  Existing DTLS implementations can continue to be used if
      a thin layer is added that handles compression/decompression.

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

1.3.  Terminology

   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 RFC 2119 [RFC2119].
   (Note that this document itself is informational, but it is
   discussing normative statements.)

   The term "byte" is used in its now customary sense as a synonym for
   "octet".


2.  Potential Problems and Possible Solutions

2.1.  Handshake Message Fragmentation

   DTLS records can be large in size for a single 6LoWPAN [RFC4944]
   payload: [IEEE.802-15-4] specifies a physical layer MTU of only 127
   bytes, which yields about 60-80 bytes of payload after adding MAC
   layer and adaptation layer headers.  Although 6LoWPAN supports the
   fragmentation of IPv6 packets into small link-layer frames, this
   doesn't really work well for constrained applications and networks.

   DTLS offers fragmentation at the handshake layer and hence can get
   around IP fragmentation.  However, this can add a significant
   overhead on the number of datagrams and bytes transferred (see
   Table 1).  Packet loss is also still a big problem for the
   constrained nodes; buffers must be large enough to hold all messages
   after reassembly and losing a single fragment will cause all
   fragments of a message flight to be retransmitted.  This is very
   likely especially during key and certificate exchange as these will
   not fit within a packet without fragmentation in most 6LoWPANs.



Hartke & Bergmann       Expires January 17, 2013                [Page 4]


Internet-Draft              Constrained DTLS                   July 2012


   +--------------+-----------------+------------------+---------------+
   |     UDP data |       Number of |  Total number of | Proportion of |
   |   size limit |       datagrams |            bytes |   header data |
   |      (bytes) |     transferred |      transferred |               |
   +--------------+-----------------+------------------+---------------+
   |           50 |              27 |            1,182 |          55 % |
   |           55 |              21 |            1,037 |          49 % |
   |           60 |              20 |            1,081 |          51 % |
   |           65 |              18 |            1,003 |          47 % |
   |           70 |              15 |              912 |          42 % |
   |           75 |              14 |              875 |          39 % |
   |           80 |              13 |              874 |          39 % |
   |           85 |              12 |              849 |          37 % |
   |           90 |              12 |              849 |          37 % |
   |        1,152 |               6 |              802 |          34 % |
   +--------------+-----------------+------------------+---------------+

    Table 1: Number of datagrams and bytes transferred using different
        limits for DTLS fragmentation in an example DTLS handshake
   (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 with raw public key certificate)

   Possible Solutions include:

   o  Use IP fragmentation instead of DTLS fragmentation.  If no X.509
      certificates are involved, the handshake messages of one flight
      typically require less than 400 bytes combined.  Since all
      messages of a flight are retransmitted anyway when a single
      fragment is lost, the difference between performing the
      fragmentation at the DTLS layer and at the IP layer is probably
      not huge.  A recipient must still be prepared to receive
      arbitrarily fragmented handshake messages at the DTLS layer,
      though.

   o  Reduce the number of bytes to be transferred, so the overhead of
      header data becomes smaller when fragmenting for small packet
      sizes, and fewer packets need to be transmitted that could
      potentially be lost:

      *  Use an out-of-band mechanism to exchange large blobs.  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.

      *  Use 6LoWPAN General Header Compression
         [I-D.bormann-6lowpan-ghc] to compress DTLS messages, as
         proposed in [DCOSS12].




Hartke & Bergmann       Expires January 17, 2013                [Page 5]


Internet-Draft              Constrained DTLS                   July 2012


      *  Use some DTLS-specific kind of Stateless Header Compression, as
         shown in Section 3.  This can significantly reduce the number
         of datagrams and bytes transferred, and in particular also the
         proportion of header data in the number of bytes transferred
         (see Table 2).

      *  Use compressed point formats for elliptic curve points.

      *  Use self-delimiting numeric values [RFC6256] instead of fixed-
         size numeric values.

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

   o  Perform the DTLS handshake over another protocol, for example,
      CoAP [I-D.ietf-core-coap] with its support for block-wise
      transfers [I-D.ietf-core-block], as shown in Section 4.

   +--------------+-----------------+------------------+---------------+
   |     UDP data |       Number of |  Total number of | Proportion of |
   |   size limit |       datagrams |            bytes |   header data |
   |      (bytes) |     transferred |      transferred |               |
   +--------------+-----------------+------------------+---------------+
   |           50 |       15 (56 %) |       592 (50 %) |          10 % |
   |           55 |       13 (62 %) |       585 (56 %) |           9 % |
   |           60 |       13 (65 %) |       621 (57 %) |          14 % |
   |           65 |       11 (61 %) |       588 (59 %) |          10 % |
   |           70 |       11 (73 %) |       573 (63 %) |           7 % |
   |           75 |       11 (79 %) |       573 (65 %) |           7 % |
   |           80 |       10 (77 %) |       567 (65 %) |           6 % |
   |           85 |       10 (83 %) |       567 (67 %) |           6 % |
   |           90 |       10 (83 %) |       567 (67 %) |           6 % |
   |        1,152 |       6 (100 %) |       617 (77 %) |          14 % |
   +--------------+-----------------+------------------+---------------+

      Table 2: Number of datagrams and bytes transferred in the same
       example DTLS handshake but using Stateless Header Compression
                                (Section 4)

2.2.  Timer Values

   DTLS leaves the choice of timer values to the implementation, but
   makes the following recommendation:

      "Implementations SHOULD use an initial timer value of 1 second
      (the minimum defined in RFC 6298 [RFC6298]) and double the value
      at each retransmission, up to no less than the RFC 6298 maximum of
      60 seconds."  [RFC6347]



Hartke & Bergmann       Expires January 17, 2013                [Page 6]


Internet-Draft              Constrained DTLS                   July 2012


   Given the time required by some algorithms when executed on a
   constrained devices (see Table 3), an initial value of 1 second can
   easily lead to spurious retransmissions.

   +-------------+--------------+-----------+------------+-------------+
   | Algorithm   | Library      |    Memory |  Execution |  Comparable |
   |             |              | footprint |       time |     RSA key |
   |             |              |   (bytes) |  (seconds) |      length |
   +-------------+--------------+-----------+------------+-------------+
   | RSA 1024    | AvrCryptolib |       640 |      199.7 |             |
   | RSA 2048    | AvrCryptolib |     1,280 |    1,587.6 |             |
   | ECDSA 160r1 | TinyECC      |       892 |        2.3 |        1024 |
   | ECDSA 192r1 | TinyECC      |     1,008 |        3.6 |        1536 |
   | ECDSA 160r1 | Wiselib      |       842 |       20.2 |        1024 |
   | ECDSA 192r1 | Wiselib      |       952 |       34.6 |        1536 |
   | ECDSA 163k1 | Relic        |     2,804 |        0.3 |        1024 |
   | ECDSA 233k1 | Relic        |     3,675 |        1.8 |        2048 |
   +-------------+--------------+-----------+------------+-------------+

    Table 3: RSA private key operation and ECDSA signature performance
                      (from [I-D.aks-crypto-sensors])

   Possible Solutions include:

   o  Adjust the timer value to meet the conditions of constrained nodes
      and low-power, lossy networks.

   o  Add some kind of acknowledgment message to DTLS that allows an
      implementation to confirm the receipt of a message before
      preparing the next message flight.

2.3.  Connection Initiation

   Nodes with very constrained main memory also suffer from the
   complexity of the DTLS handshake protocol.  We envision that the
   acceptance of DTLS as security protocol for embedded devices would
   significantly increase if a less complex connection initiation
   procedure with a smaller number of handshake messages was defined.

   Compared to TLS, DTLS exacerbates the connection initiation: A DTLS
   handshake has an additional roundtrip that results from the addition
   of a stateless cookie exchange.  This exchange is designed to prevent
   certain denial-of-service attacks: consumption of excessive server
   resources caused 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.





Hartke & Bergmann       Expires January 17, 2013                [Page 7]


Internet-Draft              Constrained DTLS                   July 2012


   Possible Solutions include:

   o  Create the DTLS connection before it is needed, so it doesn't take
      a long time to set it up when it's actually needed.  This works if
      a server has do deal with a relatively small overall number of
      clients that wish to interact with the server.  Care must be taken
      such that not all clients perform their handshake at the same
      time, as a handshake requires considerably more memory than
      keeping a connection open.  (See also Section 2.4 below.)

   o  Shorten the handshake to four flights.  This may be possible
      without losing the denial-of-service roundtrip if the cipher suite
      permits that the server remains stateless after sending the
      ServerHello and if the flight fits in one datagram (see Figure 1).


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

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

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

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

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

    Figure 1: Artist's impression of a four-flight DTLS handshake with
                              Pre-Shared Key

   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].
      The application of client puzzles to TLS has been shown
      [USENIX01].  However, a puzzle would be needed that ideally takes
      less effort for a constrained device and more effort for a less
      constrained device.






Hartke & Bergmann       Expires January 17, 2013                [Page 8]


Internet-Draft              Constrained DTLS                   July 2012


2.4.  Connection Closure

   Although a connection needs considerably less memory after a
   handshake has finished, it still requires, e.g., around 80 bytes with
   AES-128-CCM [I-D.mcgrew-tls-aes-ccm] for the keys, sequence numbers
   and anti-replay window.  More memory is needed if session resumption
   is supported, to keep the 48-byte master secret and negotiated
   connection parameters.  This limits how many connections a
   constrained device can maintain at a given time.  Often, constrained
   devices will have a fixed number of "slots" for connections rather
   than allocating memory dynamically for each connection.

   DTLS provides a facility for secure connection closure.  When a valid
   closure alert is received, an implementation can be assured that no
   further data will be received on that connection.  It is noteworthy,
   though, that the closure alert is not a handshake message and thus is
   not retransmitted when packet loss occurs.

   Possible Solutions include:

   o  Maintain the session for as long as possible.  When the server
      runs out of resources, it can close connections, e.g., using a
      Least Frequently Used (LFU) eviction policy.  The client simply
      assumes that the connection is active until the server rejects its
      application data, in which case the client initiates a new
      connection.

   o  Use the DTLS Heartbeat Extension [RFC6520] to figure out from time
      to time if the connection is still active.

2.5.  Application Data Fragmentation

   Messages larger than an IP fragment result in undesired packet
   fragmentation.  DTLS does not support fragmentation of application
   data.  If an implementation of an application layer protocol such as
   CoAP [I-D.ietf-core-coap] wants to avoid IP fragmentation, it must
   fit the application data (e.g., a CoAP message) and all headers
   within a single IP packet.

   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 authentication
   tag.  Thus, cipher suites like TLS_PSK_WITH_AES_128_CCM_8 or
   TLS_ECDHE_ECDSA_AES_128_CCM_8 requires 16 additional bytes, leading
   to an overall overhead of 29 bytes for the header of each encrypted
   DTLS packet.  With packet sizes of 60-80 bytes, this takes a
   considerable portion of the available packet size away (see Table 4).




Hartke & Bergmann       Expires January 17, 2013                [Page 9]


Internet-Draft              Constrained DTLS                   July 2012


   +------------------+------------------------+-----------------------+
   |    UDP data size |   Number of bytes left |    ... with Stateless |
   |    limit (bytes) |   for application data |    Header Compression |
   +------------------+------------------------+-----------------------+
   |               50 |              21 (42 %) |             39 (78 %) |
   |               55 |              26 (47 %) |             44 (80 %) |
   |               60 |              31 (52 %) |             49 (82 %) |
   |               65 |              36 (55 %) |             54 (83 %) |
   |               70 |              41 (59 %) |             59 (84 %) |
   |               75 |              46 (61 %) |             64 (85 %) |
   |               80 |              51 (64 %) |             69 (86 %) |
   |               85 |              56 (66 %) |             74 (87 %) |
   |               90 |              61 (68 %) |             79 (88 %) |
   |            1,152 |           1,123 (97 %) |          1,141 (99 %) |
   +------------------+------------------------+-----------------------+

    Table 4: Number of bytes left for data in an ApplicationData record
     using DTLS and DTLS with Stateless Header Compression (Section 4)

   Possible Solutions include:

   o  Elide the GenericAEADCipher.nonce_explicit field when AES-CCM is
      used.  The GenericAEADCipher.nonce_explicit field is set to the
      16-bit epoch concatenated with the 48-bit sequence number, which
      means that the epoch and sequence number are unnecessarily
      included twice in each record.

   o  Elide the DTLS version field where it is implicitly clear.  Since
      the DTLS version is negotiated in the handshake, there should not
      be a need to specify the DTLS version in each and every record.

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

   For example, when using the Stateless Header Compression presented in
   Section 3 and eliminating the redundant epoch and sequence number
   information, the number of bytes left in an ApplicationData record
   for application data can be significantly increased (see Table 4).

2.6.  Data size

   As fragmented handshake messages can arrive at a constrained node in
   any order, the receiver must provide a message buffer that is large
   enough to hold multiple fragments.  When several handshake messages



Hartke & Bergmann       Expires January 17, 2013               [Page 10]


Internet-Draft              Constrained DTLS                   July 2012


   forming a single flight are sent out in parallel, it is likely that
   the receiver's resources are too limited to order fragments from
   distinct handshake messages.  Avoiding this might require additional
   resources on the server side to ensure serialization of a flight's
   messages.

   Furthermore, since handshake messages can be fragmented arbitrarily
   and with overlaps, the receiver must, in addition to the message
   buffer, keep track of the fragments received so far.

   Possible retransmissions require even more buffer space as replay-
   protection requires encryption of every single packet that is to be
   transmitted.  In particular, this renders destructive in-place
   encryption impossible as the source data must be preserved.

   Possible Solutions include:

   o  Use the same sequence number when retransmitting a message, so the
      plaintext could be encrypted in-place without the need for a
      second buffer.  The security implications of this change need to
      be carefully analyzed.

   o  Favour cryptographic algorithms that use less memory, possibly
      resulting in a slower performance.

   o  Add some kind of acknowledgment message to DTLS that allows an
      receiver to confirm the receipt of a message, and let the sender
      wait for the acknowledgment before it sends the next part of the
      flight.

2.7.  Code size

   Although probably not as severe as data size limits, the code size of
   a DTLS implementation also can play a role, in particular for
   constrained devices at the lower bound of Class 1 devices.

   Possible Solutions include:

   o  Avoid static tables for cryptographic functions where possible, as
      typical embedded platforms are more restricted in RAM than in non-
      volatile memory such as flash ROM.  Instead, their procedural
      equivalent is to be used, although less efficient during run-time.

   o  Use using pre-composed messages instead of writing code, e.g., for
      encoding or decoding ASN.1 structures, as shown in Appendix A.






Hartke & Bergmann       Expires January 17, 2013               [Page 11]


Internet-Draft              Constrained DTLS                   July 2012


3.  Stateless Header Compression

   Stateless Header Compression compresses the headers of records and
   handshake messages.  The compression is lossless, does not increase
   the record length and is done without explicitly building any
   compression context state.

   The Finished MAC is computed as if each handshake message had been
   sent uncompressed.

3.1.  Records

   Records are compressed by specifying the type, version, epoch,
   sequence_number and length fields using a variable number of bytes.
   A prefix is added in front of the structure to indicate the length of
   each field or to specify the value of the field directly.  If the
   value is specified directly, the field itself is elided.  The format
   of the prefix is as follows:

                       0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |0| T | V |  E  |1 1 0|  S  | L |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields in the prefix are defined as follows:

   T: Describes the type field.

      0 - Content Type 20 (ChangeCipherSpec)
      1 - 8-bit type field
      2 - Content Type 22 (Handshake)
      3 - Content Type 23 (Application Data)

   V: Describes the version field.

      0 - Version 254.255 (DTLS 1.0)
      1 - 16-bit version field
      2 - Version 254.253 (DTLS 1.2)
      3 - Reserved for future use

   E: Describes the epoch field.

      0 - Epoch 0
      1 - Epoch 1
      2 - Epoch 2
      3 - Epoch 3
      4 - Epoch 4



Hartke & Bergmann       Expires January 17, 2013               [Page 12]


Internet-Draft              Constrained DTLS                   July 2012


      5 - 8-bit epoch field
      6 - 16-bit epoch field
      7 - Implicit -- same as previous record in the datagram

   S: Describes the sequence_number field.

      0 - Sequence number 0
      1 - 8-bit sequence_number field
      2 - 16-bit sequence_number field
      3 - 24-bit sequence_number field
      4 - 32-bit sequence_number field
      5 - 40-bit sequence_number field
      6 - 48-bit sequence_number field
      7 - Implicit -- number of previous record in the datagram + 1

   L: Describes the length field.

      0 - Length 0
      1 - 8-bit length field
      2 - 16-bit length field
      3 - Implicit -- last record in the datagram

3.2.  Handshake Messages

   Handshake messages are compressed in a similar way.  A prefix is
   added in front of the structure to indicate the length of each field
   or to specify the value of the field directly.  If the value is
   specified directly, the field itself is elided.  The format of the
   prefix is as follows:

                       0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |0 0|   T   | L |   S   | O | C |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields in the prefix are defined as follows:

   T: Describes the msg_type field.

      0 - 8-bit msg_type field
      1 - Handshake Type 1 (Client Hello)
      2 - Handshake Type 2 (Server Hello)
      3 - Handshake Type 3 (Hello Verify Request)
      4 - Reserved for future use
      5 - Reserved for future use
      6 - Reserved for future use
      7 - Handshake Type 11 (Certificate)



Hartke & Bergmann       Expires January 17, 2013               [Page 13]


Internet-Draft              Constrained DTLS                   July 2012


      8 - Handshake Type 12 (Server Key Exchange)
      9 - Handshake Type 13 (Certificate Request)
      10 - Handshake Type 14 (Server Hello Done)
      11 - Handshake Type 15 (Certificate Verify)
      12 - Handshake Type 16 (Client Key Exchange)
      13 - Reserved for future use
      14 - Reserved for future use
      15 - Handshake Type 20 (Finished)

   L: Describes the length field.

      0 - Implicit -- last message in the record
      1 - 8-bit length field
      2 - 16-bit length field
      3 - 24-bit length field

   S: Describes the message_seq field.

      0 - Message sequence number 0
      1 - Message sequence number 1
      2 - Message sequence number 2
      3 - Message sequence number 3
      4 - Message sequence number 4
      5 - Message sequence number 5
      6 - Message sequence number 6
      7 - Message sequence number 7
      8 - Message sequence number 8
      9 - Message sequence number 9
      10 - Message sequence number 10
      11 - Message sequence number 11
      12 - Message sequence number 12
      13 - 8-bit message_seq field
      14 - 16-bit message_seq field
      15 - Implicit -- number of previous message in the record + 1

   O: Describes the fragment_offset field.

      0 - Offset 0
      1 - 8-bit fragment_offset field
      2 - 16-bit fragment_offset field
      3 - 24-bit fragment_offset field

   C: Describes the fragment_length field.

      0 - Implicit -- last message in the record
      1 - 8-bit fragment_length field
      2 - 16-bit fragment_length field
      3 - 24-bit fragment_length field



Hartke & Bergmann       Expires January 17, 2013               [Page 14]


Internet-Draft              Constrained DTLS                   July 2012


4.  RESTful DTLS Handshake

   Where DTLS is used in conjunct with the Constrained Application
   Protocol (CoAP) [I-D.ietf-core-coap], it might be beneficial to use
   CoAP with its support for block-wise transfers [I-D.ietf-core-block]
   instead of DTLS's convoluted handshake protocol to transport DTLS
   handshake messages.

   CoAP, like HTTP, is designed for applications following the REST
   architectural style [REST].  So the DTLS connection is modeled as a
   CoAP resource which gets created when a client wants to initiate a
   connection, and gets updated to modify the state and parameters of
   the connection.  A well-known URI path [RFC5785] is used to identify
   a collection resource that models the set of active connections and
   allows new connections to be created.

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

   POST /.well-known/dtls
   ClientHello                  ----->

                                         1.xx Verify
                                <-----   HelloVerifyRequest


   POST /.well-known/dtls
   ClientHello                  ----->

                                         2.01 Created /session/4ad6bc29
                                         ServerHello
                                         Certificate*
                                         ServerKeyExchange*
                                         CertificateRequest*
                                <-----   ServerHelloDone

   PATCH /session/4ad6bc29
   Certificate*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished                     ----->

                                         2.04 Changed
                                         [ChangeCipherSpec]
                                <-----   Finished

               Figure 2: Message Flights for Full Handshake



Hartke & Bergmann       Expires January 17, 2013               [Page 15]


Internet-Draft              Constrained DTLS                   July 2012


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

   PATCH /session/4ad6bc29
   ClientHello                  ----->

                                         2.04 Changed
                                         ServerHello
                                         [ChangeCipherSpec]
                                <-----   Finished

   PATCH /session/4ad6bc29
   [ChangeCipherSpec]
   Finished                     ----->

                                <-----   2.04 Changed

         Figure 3: Message Flights for Session-Resuming Handshake

   There are the following possible operations:

   o  POST to well-known URI: requests the server to create a new
      session resource.

   o  PATCH session resource: requests the server to change session
      parameters, or to resume a session.

   o  GET session resource: returns a representation of the session.

   o  DELETE session resource: requests the server to delete the session
      resource and free all resources related to the session.

   The following protocols and URI schemes are used:

   o  CoAP [I-D.ietf-core-coap]

   o  coap+codtls://

   The following well-known URIs are used:

   o  /.well-known/dtls

   The following media types are used:

   o  application/dtls

   (The exact definition of these items is TBD.)




Hartke & Bergmann       Expires January 17, 2013               [Page 16]


Internet-Draft              Constrained DTLS                   July 2012


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


6.  IANA Considerations

   This draft includes no request to IANA.


7.  Acknowledgements

   Thanks to Angelo P. Castellani, Stefan Jucker and Shahid Raza for
   helpful comments and discussions that have shaped the document.


8.  References

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

8.2.  Informative References

   [DCOSS12]  Raza, S., Trabalza, D., and T. Voigt, "6LoWPAN Compressed
              DTLS for CoAP", 8th IEEE International Conference on
              Distributed Computing in Sensor Systems, May 2012.

   [I-D.aks-crypto-sensors]
              Sethi, M., Arkko, J., Keranen, A., and H. Rissanen,
              "Practical Considerations and Implementation Experiences
              in Securing Smart Object Networks",
              draft-aks-crypto-sensors-02 (work in progress),
              March 2012.

   [I-D.bormann-6lowpan-ghc]
              Bormann, C., "6LoWPAN Generic Compression of Headers and
              Header-like Payloads", draft-bormann-6lowpan-ghc-04 (work
              in progress), March 2012.



Hartke & Bergmann       Expires January 17, 2013               [Page 17]


Internet-Draft              Constrained DTLS                   July 2012


   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-08 (work in progress),
              February 2012.

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

   [I-D.ietf-lwig-guidance]
              Bormann, C., "Guidance for Light-Weight Implementations of
              the Internet Protocol Suite", draft-ietf-lwig-guidance-01
              (work in progress), July 2012.

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

   [I-D.ietf-tls-oob-pubkey]
              Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
              Tschofenig, "TLS Out-of-Band Public Key Validation",
              draft-ietf-tls-oob-pubkey-03 (work in progress),
              April 2012.

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

   [I-D.mcgrew-tls-aes-ccm-ecc]
              McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM ECC Cipher Suites for TLS",
              draft-mcgrew-tls-aes-ccm-ecc-02 (work in progress),
              October 2011.

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

   [IEEE.802-15-4]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              15.4: Wireless Medium Access Control (MAC) and Physical



Hartke & Bergmann       Expires January 17, 2013               [Page 18]


Internet-Draft              Constrained DTLS                   July 2012


              Layer (PHY) Specifications for Low-Rate Wireless Personal
              Area Networks (WPANs)", IEEE Standard 802.15.4,
              September 2006, <http://standards.ieee.org/getieee802/
              download/802.15.4-2006.pdf>.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Ph.D. Dissertation,
              University of California, Irvine, 2000, <http://
              www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.

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

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

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

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              June 2011.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520, February 2012.

   [SOS12]    Arkko, J. and H. Tschofenig, "Conclusions from the
              Workshop on Smart Object Security", Workshop on Smart
              Object Security, March 2012, <http://
              www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/
              slides/sos-conclusions.ppt>.

   [USENIX01]
              Dean, D. and A. Stubblefield, "Using Client Puzzles to
              Protect TLS", 10th USENIX Security Symposium, August 2001,
              <http://static.usenix.org/events/sec01/full_papers/dean/
              dean.pdf>.






Hartke & Bergmann       Expires January 17, 2013               [Page 19]


Internet-Draft              Constrained DTLS                   July 2012


Appendix A.  Templates

   When elliptic curve cryptography is used, building and parsing the
   bodies of Certificate, ServerKeyExchange and ClientKeyExchange
   messages mainly involves the encoding and decoding of elliptic curve
   points.  The points are encapsulated in a mix of DTLS structures and
   ASN.1 sequences.  For a given elliptic curve, some parts of a message
   body are static, which allows using pre-composed messages instead of
   writing lots of memory consuming code pertaining to DTLS and ASN.1.

   This appendix provides templates for the bodies of the Certificate,
   ServerKeyExchange and ClientKeyExchange messages used in a DTLS
   handshake with raw public key certificates [I-D.ietf-tls-oob-pubkey]
   and the ECDHE_ECDSA key exchange [RFC4492].

   The templates are given for the named curves secp256r1, secp384r1 and
   secp521r1; these curves are equivalent to the NIST P-256, P-384, and
   P-521 curves.  They are required in [I-D.mcgrew-tls-aes-ccm-ecc].
   The same curve is used in each case for both the raw public key
   certificate and the ephemeral keys.  Points are represented in
   uncompressed point format.

   Note: The templates have not been independently verified yet.

A.1.  secp256r1

   Raw Public Key Certificate:

              30 59 30 13 06 07 2a 86  48 ce 3d 02 01 06 08 2a
              86 48 ce 3d 03 01 07 03  42 00 04 __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __

                      ECDSA-capable public key (x, y)















Hartke & Bergmann       Expires January 17, 2013               [Page 20]


Internet-Draft              Constrained DTLS                   July 2012


   Server Key Exchange:

              03 00 17 41 04 __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ 00 46 30  44 02 20 __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ 02 20 __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __

        ephemeral ECDH public key (x, y) and ECDSA signature (r, s)

   Client Key Exchange:

              41 04 __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __

                     ephemeral ECDH public key (x, y)

A.2.  secp384r1

   Raw Public Key Certificate:

              30 76 30 10 06 07 2a 86  48 ce 3d 02 01 06 05 2b
              81 04 00 22 03 62 00 04  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __

                      ECDSA-capable public key (x, y)













Hartke & Bergmann       Expires January 17, 2013               [Page 21]


Internet-Draft              Constrained DTLS                   July 2012


   Server Key Exchange:

              03 00 18 61 04 __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ 00 66 30  64 02 30 __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ 02 30 __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __

        ephemeral ECDH public key (x, y) and ECDSA signature (r, s)

   Client Key Exchange:

              61 04 __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __

                     ephemeral ECDH public key (x, y)

A.3.  secp521r1

   Raw Public Key Certificate:

              30 81 9b 30 10 06 07 2a  86 48 ce 3d 02 01 06 05
              2b 81 04 00 23 03 81 86  00 04 __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __

                      ECDSA-capable public key (x, y)





Hartke & Bergmann       Expires January 17, 2013               [Page 22]


Internet-Draft              Constrained DTLS                   July 2012


   Server Key Exchange:

              03 00 19 85 04 __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ 00 8b 30 81 88 02 42
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ 02 42 __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __

        ephemeral ECDH public key (x, y) and ECDSA signature (r, s)

   Client Key Exchange:

              85 04 __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __ __ __  __ __ __ __ __ __ __ __
              __ __ __ __ __ __

                     ephemeral ECDH public key (x, y)















Hartke & Bergmann       Expires January 17, 2013               [Page 23]


Internet-Draft              Constrained DTLS                   July 2012


Authors' Addresses

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

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


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

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































Hartke & Bergmann       Expires January 17, 2013               [Page 24]


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