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, . [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . [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, . [USENIX01] Dean, D. and A. Stubblefield, "Using Client Puzzles to Protect TLS", 10th USENIX Security Symposium, August 2001, . 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]