CoRE Working Group K. Hartke Internet-Draft O. Bergmann Intended status: Informational Universitaet Bremen TZI Expires: September 14, 2012 March 13, 2012 Datagram Transport Layer Security in Constrained Environments draft-hartke-core-codtls-01 Abstract We consider some obstacles in implementing Datagram Transport Layer Security (DTLS) in constrained environments, and present some ideas for a constrained version of DTLS that is friendly to constrained nodes and networks. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hartke & Bergmann Expires September 14, 2012 [Page 1] Internet-Draft Constrained DTLS March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementing DTLS in Constrained Environments . . . . . . . . 3 3. Constrained Datagram Transport Layer Security . . . . . . . . 5 3.1. Smaller messages . . . . . . . . . . . . . . . . . . . . . 5 3.2. Less state . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Shorter handshakes . . . . . . . . . . . . . . . . . . . . 7 3.4. Fewer transmissions . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Hartke & Bergmann Expires September 14, 2012 [Page 2] Internet-Draft Constrained DTLS March 2012 1. Introduction Nodes that take part in the "Internet of Things" often have strict limitations regarding their computational power, memory size (both, ROM and RAM), and power management [I-D.bormann-lwig-guidance]. Network communication, especially wireless, also imposes constraints that need to be considered during protocol design, e.g. low bitrate, variable delay and possibly high packet loss. Moreover, frames at the link layer might be much smaller than the IPv6 minimum MTU of 1280 octets and therefore require additional mapping mechanisms such as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks, which in turn may exacerbate the limitations of the network: E.g., as high loss rates are anticipated by design, application protocols usually try to avoid fragmentation at the network layer. However, application protocols often delegate security mechanisms to transport layer security protocols. More often than not, the protocol overhead from securing the communication is highly relevant to the overall performance of the systems. One protocol that has received significant attention recently for constrained node/network applications is Datagram Transport Layer Security (DTLS) [RFC6347]. DTLS is derived from and inherits some characteristics from TLS [RFC5246], which has not been designed with constrained nodes/networks in mind. The present document considers some obstacles in implementing DTLS in constrained environments, and presents some ideas for a constrained version of DTLS that is friendly to constrained nodes and networks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Implementing DTLS in Constrained Environments As an example for the TLS traits that DTLS inherits (and exacerbates), DTLS has a per-record overhead of 13 octets for the record header. AEAD ciphers such as AES-CCM [I-D.mcgrew-tls-aes-ccm] eat up additional space to carry the explicit nonce and the MAC. Thus, the cipher suite TLS_PSK_WITH_AES_128_CCM_8 suggested by CoAP [I-D.ietf-core-coap] for Pre-Shared Key mode requires 16 additional octets, leading to an overall overhead of 29 octets for each encrypted DTLS packet. Although DTLS offers fragmentation at the record layer and hence can get around IP fragmentation, packet loss still is a big problem for Hartke & Bergmann Expires September 14, 2012 [Page 3] Internet-Draft Constrained DTLS March 2012 constrained nodes; buffers must be large enough to hold all fragments for reassembly and losing a single fragment will cause the entire DTLS message to be retransmitted. This is very likely especially for messages at the handshake layer during key and certificate exchange as these will not fit within a single frame in most 6LoWPANs. Besides buffer space for packet reassembly at the receiver, a sender must provide extra buffer space for payload encoding. In particular, the use of some AEAD ciphers requires inclusion of sequence numbers in the ciphertext calculation. The sender therefore must keep the plaintext version of each message in a separate buffer and thus cannot encrypt it in place. Nodes with very constrained main memory also suffer from the complex DTLS handshake protocol. Figure 1 shows the message flights required for a full DTLS handshake. We envision that the acceptance of DTLS as security protocol for embedded devices would significantly increase if a faster setup procedure with a smaller number of handshake messages was defined. Client Server ------ ------ ClientHello --------> Flight 1 <------- HelloVerifyRequest Flight 2 ClientHello --------> Flight 3 ServerHello \ Certificate* \ ServerKeyExchange* Flight 4 CertificateRequest* / <-------- ServerHelloDone / Certificate* \ ClientKeyExchange \ CertificateVerify* Flight 5 [ChangeCipherSpec] / Finished --------> / [ChangeCipherSpec] \ Flight 6 <-------- Finished / Figure 1: The six message flights of a full DTLS handshake Hartke & Bergmann Expires September 14, 2012 [Page 4] Internet-Draft Constrained DTLS March 2012 3. Constrained Datagram Transport Layer Security This section presents a random collection of ideas for a constrained version of DTLS ("Constrained DTLS") that is friendly to constrained nodes by enabling small buffer sizes, reduced state and fewer and smaller messages -- at the cost of being constrained. The ideas fall into the following categories: Implementation guidance: Implementation techniques for achieving light-weight implementations of DTLS, without affecting conformance to the relevant specifications or interoperability with other implementations. This includes techniques for reducing complexity, memory footprint, or power usage. The result may eventually be incorporated into [I-D.bormann-lwig-guidance]. Stateless header compression: DTLS records get compressed without explicitly building any compression context state. This is done by using shorter forms to represent the same bits of information or relying on information that is already shared by client and server. Existing DTLS implementations can continue to be used if a thin layer is added that handles compression/decompression. Protocol profile: Use of DTLS in a particular way, for example, by changing MAYs into MUSTs or MUST NOTs, or by requiring or precluding certain extensions or cipher suites. Existing DTLS implementations ought to continue to be used without change if they can be configured accordingly. Other: Breaking changes. New implementations are required that do not interoperate with implementations of DTLS. 3.1. Smaller messages o When AES-CCM [I-D.mcgrew-tls-aes-ccm] is used, the GenericAEADCipher.nonce_explicit field is set to the 16-bit epoch concatenated with the 48-bit sequence number. This means the epoch and sequence number are included twice in each record. Stateless header compression could eliminate this redundancy. o Since the DTLS version is negotiated in the handshake, there should be no need to specify the DTLS version in each and every record. Stateless header compression could eliminate the DTLS version field where it is implicitly clear. o DTLS records specify their length so multiple records can be transmitted in a single datagram. When DTLS is used with UDP (which preserves the message boundaries of all sent messages), Hartke & Bergmann Expires September 14, 2012 [Page 5] Internet-Draft Constrained DTLS March 2012 stateless header compression could eliminate the length field of the last record in a datagram. o Use of self-delimiting numeric values [RFC6256] instead of fixed- size numeric values. For example, the 16-bit epoch is either 0 or 1 in most cases. o Use of a bit field instead of multiple type fields to indicate which handshake messages are present in a datagram. 3.2. Less state o The handshake messages within a flight can be processed in any order: they essentially all just mutate the connection state without any interdependence. The resulting state is not needed until all messages have been received. However, the TLS Finished message includes the hash of all handshake messages which, for this purpose, need to be processed in the right order for the hash to be correct. If this was not required, the need for large buffers to queue reordered messages for future handling could be alleviated. An alternative to the hash of the concatenation of all the Handshake structures might be to compute the hash of the current and the pending connection state (security parameters, client and server write parameters, negotiated extensions, etc.). o The reassembly of fragmented handshake messages requires large buffers, because buffer space is not only needed to reassemble the next expected message, but also reordered fragments of following messages. If entities are required to use an out-of-band mechanism to exchange large blobs, then the fragmentation of messages could be removed altogether. For example, the TLS Cached Information Extension [I-D.ietf-tls-cached-info] allows to omit the exchange of fairly static information, such as the server certificate, if this information is already available. o TLS defines four logical connection states: the current read and write states, and the pending read and write states. Records are processed under the current states; pending states are needed during a (re-)handshake until ChangeCipherSpec makes the pending states current. The maintenance of a pool of connection states can lead to considerable complexity in an implementation. To reduce complexity, implementations can choose to not support Hartke & Bergmann Expires September 14, 2012 [Page 6] Internet-Draft Constrained DTLS March 2012 rehandshakes. This allows the implementation to logically keep only the following connection states: the read and write states of epoch 0 (which specifies that no encryption, compression, or MAC is used), and the read and writes states of epoch 1. These four states can be implemented in a very compact way. o In DTLS, each retransmission is a new record with a new sequence number value. If the sequence number if part of the nonce, this means that a sender cannot encrypt plaintext in-place but must keep the plaintext in a separate buffer until the transmission succeeds or eventually times out. If retransmission would not use a new sequence number, plaintext could be encrypted in-place without the need for a second buffer. 3.3. Shorter handshakes o A DTLS handshake has two additional flights when compared to TLS, resulting from the addition of a stateless cookie exchange. This exchange is designed to prevent certain denial-of-service attacks: consumption of excessive server resources cause by the transmission of a series of handshake initiation requests, and use of the server as an amplifier by sending connection initiation messages with a forged source of the victim. If the cipher suite permits that the server remains stateless after sending ServerHello..ServerHelloDone, and ServerHello..ServerHelloDone fits in one datagram, then a full handshake could perhaps be shortened to four flights (see Figure 2). Hartke & Bergmann Expires September 14, 2012 [Page 7] Internet-Draft Constrained DTLS March 2012 Client Server ------ ------ ClientHello --------> Flight 1 HelloVerifyRequest \ ServerHello Flight 2 <-------- ServerHelloDone / (remain stateless) ClientHello \ "ServerHello" \ ClientKeyExchange Flight 3 [ChangeCipherSpec] / Finished --------> / [ChangeCipherSpec] \ Flight 4 <-------- Finished / Figure 2: Artist's impression of a four-flight DTLS PSK handshake o As an alternative, client puzzles could be used as a mechanism for mitigating denial-of-service attacks, resulting in a four-flight exchange similar to the one in HIP DEX [I-D.moskowitz-hip-rg-dex] (shown in Figure 3). The application of client puzzles to TLS has been shown [Usenix01]. However, in the case the client is a constrained node, client puzzles may be too challenging. Initiator Responder 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 3: The four-packet HIP DEX exchange Hartke & Bergmann Expires September 14, 2012 [Page 8] Internet-Draft Constrained DTLS March 2012 3.4. Fewer transmissions o DTLS allows multiple messages of the same ContentType to be coalesced into a single record. As a matter of implementation quality, implementations should coalesce as many messages of the same ContentType into a single record as possible. Similarly, implementations should not fragment a message if the record fits in a single datagram. o In DTLS, when a datagram carrying one part of a flight is lost, the whole flight needs to be retransmitted, possibly requiring the retransmission of the whole previous flight. A thin reliability layer such as the one provided by CoAP [I-D.ietf-core-coap] could be used, such that only the messages that are lost would need to be retransmitted instead of all messages of an entire flight. 4. Security Considerations Beyond stateless header compression and profiling, changes to the TLS/DTLS protocol need to be performed extremely carefully. No analysis has been done in the present version of this draft. 5. IANA Considerations This draft includes no request to IANA. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 6.2. Informative References [I-D.bormann-lwig-guidance] Bormann, C., "Guidance for Light-Weight Implementations of Hartke & Bergmann Expires September 14, 2012 [Page 9] Internet-Draft Constrained DTLS March 2012 the Internet Protocol Suite", draft-bormann-lwig-guidance-01 (work in progress), January 2012. [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.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.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.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-05 (work in progress), March 2011. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, May 2011. [Usenix01] Dean, D. and A. Stubblefield, "Using Client Puzzles to Protect TLS", 2001, . Hartke & Bergmann Expires September 14, 2012 [Page 10] Internet-Draft Constrained DTLS March 2012 Authors' Addresses Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63905 Fax: +49-421-218-7000 Email: hartke@tzi.org 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 14, 2012 [Page 11]