CoRE Working Group K. Hartke Internet-Draft O. Bergmann Intended status: Informational Universitaet Bremen TZI Expires: September 7, 2012 March 6, 2012 Datagram Transport Layer Security in Constrained Environments draft-hartke-core-codtls-00 Abstract We consider some obstacles when it comes to implement Datagram Transport Layer Security (DTLS) in constrained environments, and present some ideas for a constrained version of DTLS that is friendly to constrained devices. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hartke & Bergmann Expires September 7, 2012 [Page 1] Internet-Draft Constrained DTLS March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementing DTLS in Constrained Environments . . . . . . . . . 3 3. Constrained Datagram Transport Layer Security . . . . . . . . . 4 3.1. Smaller messages . . . . . . . . . . . . . . . . . . . . . 4 3.2. Less state . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Shorter handshakes . . . . . . . . . . . . . . . . . . . . 6 3.4. Fewer transmissions . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Hartke & Bergmann Expires September 7, 2012 [Page 2] Internet-Draft Constrained DTLS March 2012 1. Introduction In Section 2, we consider some obstacles when it comes to implement Datagram Transport Layer Security (DTLS) [RFC6347] in constrained environments. In Section 3, we present some ideas for a constrained version of DTLS that is friendly to constrained devices by enabling small buffer sizes, reduced state and fewer and smaller messages -- at the cost of being constrained. 2. Implementing DTLS in Constrained Environments Nodes that take part in the "Internet of Things" often have strict limitations regarding their computational power, memory size (both, ROM and RAM), and power management. Network communication, especially wireless, also imposes constraints that need to be considered during protocol design, e.g. small bandwidth, variable delay and possibly high packet loss. Moreover, frames at the link layer might be too small for the IPv6 minimum MTU of 1280 bytes and therefore require additional mapping mechanisms such as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks. As high loss rates are anticipated by design, application protocols usually try to avoid fragmentation at the network layer. More often than not, the protocol overhead from securing the communication is not taken into consideration. As an example, DTLS has a per-record overhead of 13 bytes for the record header. AEAD ciphers such as AES-CCM [I-D.mcgrew-tls-aes-ccm] eat up additional space to carry the explicit nonce and the MAC. Thus, the cipher suite TLS_PSK_WITH_AES_128_CCM_8 suggested by CoAP [I-D.ietf-core-coap] for Pre-Shared Key mode requires 16 bytes, leading to an overall of 29 bytes for each encrypted DTLS packet. Although DTLS offers fragmentation at the record layer and hence can get around IP fragmentation, packet loss still is a big problem for constrained devices as buffers must be large enough to hold all fragments for reassembly and losing a single fragment will cause the entire message flight to be retransmitted. (TODO: Because the frame size is so small, it is actually quite likely that records need to be fragmented and that records of the same message flight are transmitted in separate datagrams. This means that message loss and reordering become increasingly probable.) (TODO: In DTLS, each retransmission is a new record with a new sequence number value. This means that a sender cannot encrypt Hartke & Bergmann Expires September 7, 2012 [Page 3] Internet-Draft Constrained DTLS March 2012 plaintext in-place but must keep the plaintext in a separate buffer until the transmission succeeds or eventually times out.) (TODO: Six message flights for a full DTLS handshake (see Figure 1) are at least two too many.) (TODO: We expect that nodes communicate with the same small set of nodes over a very long time with low traffic. However, nodes may not be able to keep even a small number of sessions open for extended periods of time.) Client Server ------ ------ ClientHello --------> Flight 1 <------- HelloVerifyRequest Flight 2 ClientHello --------> Flight 3 ServerHello \ Certificate* \ ServerKeyExchange* Flight 4 CertificateRequest* / <-------- ServerHelloDone / Certificate* \ ClientKeyExchange \ CertificateVerify* Flight 5 [ChangeCipherSpec] / Finished --------> / [ChangeCipherSpec] \ Flight 6 <-------- Finished / Figure 1: Message flights for full handshake 3. Constrained Datagram Transport Layer Security 3.1. Smaller messages o DTLS allows multiple messages of the same ContentType to be coalesced into a single record. As a matter of implementation quality, implementations should coalesce as many messages of the same ContentType into a single record as possible. Similarly, implementations should not fragment a message if the record fits in a single datagram. Hartke & Bergmann Expires September 7, 2012 [Page 4] Internet-Draft Constrained DTLS March 2012 o Stateless header compression (cf. [RFC6282]): * When AES-CCM [I-D.mcgrew-tls-aes-ccm] (a set of AEAD cipher suites) is used, the GenericAEADCipher.nonce_explicit field is set to the 16-bit epoch concatenated with the 48-bit sequence number. This means the epoch and sequence number are included twice in each record. Stateless header compression could eliminate this redundancy. * Similarly, if the DTLS version is negotiated in the handshake, there is no need to specify the DTLS version in each and every record. Stateless header compression could eliminate the DTLS version field where it is implicitly clear. * DTLS records specify their length so multiple records can be transmitted in a single datagram. When DTLS is used with UDP, stateless header compression could eliminate the length field of the last record in a datagram. o Use of self-delimiting numeric values [RFC6256] instead of fixed- size numeric values. o Elliptic curve cryptography for small key sizes: "Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments." [RFC4492] 3.2. Less state o The Finished message includes the hash of all handshake messages which, for this purpose, need to processed in the right order. If this would not be required, handshake messages within a flight could be processed in any order, alleviating the need for large buffers to bring reordered messages back into order. An alternative to the hash of the concatenation of all the Handshake structures might be to compute the hash of the pending connection state (i.e. the SecurityParameters structure, client and server write parameters, negotiated extensions, etc.). o If entities use an out-of-band mechanism to exchange large blobs such as certificates (e.g., CoAP [I-D.ietf-core-coap]), then fragmentation could be removed altogether. o (TODO: If the possibility of rehandshakes was constrained/removed, there would be no need for current and pending, read and write state.) Hartke & Bergmann Expires September 7, 2012 [Page 5] Internet-Draft Constrained DTLS March 2012 o (TODO: If retransmission would not use a new sequence number, plaintext could be encrypted in-place without the need for a second buffer.) 3.3. Shorter handshakes o Client puzzles have been proposed as a mechanism for mitigating denial-of-service attacks. Client puzzles could be used in DTLS to create a four-flight exchange similiar to the one in HIP DEX [I-D.moskowitz-hip-rg-dex] (shown in Figure 2). The application to TLS has been shown [Usenix01]. o TLS False Start [I-D.bmoeller-tls-falsestart]: Achieves an improvement of one round-trip time for full handshakes if the client sends application data first and for abbreviated handshakes if the server sends application data first. o TLS Snap Start [I-D.agl-tls-snapstart]: Eliminates the latency of handshakes when the client has prior knowledge about the server. This prior knowledge is not secret and may be obtained from third parties (e.g., a CoRE Resource Directory [I-D.shelby-core-resource-directory]) and cached for significant periods of time. Initiator Responder I1: --------------------------> select precomputed R1 R1: puzzle, PK <------------------------- solve puzzle remain stateless PK Encrypt x I2: solution, PK, ECR(DH,secret x), mac --------------------------> check puzzle check mac PK Encrypt y R2: PK, ECR(DH,secret y), mac <-------------------------- check mac Figure 2: Four-packet HIP DEX exchange Hartke & Bergmann Expires September 7, 2012 [Page 6] Internet-Draft Constrained DTLS March 2012 3.4. Fewer transmissions o (TODO: Use CON/ACK/RST/NON so only lost messages need to retransmitted instead of the whole flight.) 4. Security Considerations Security issues are discussed throughout this memo. 5. IANA Considerations This memo includes no request to IANA. 6. References 6.1. Normative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 6.2. Informative References [I-D.agl-tls-snapstart] Langley, A., "Transport Layer Security (TLS) Snap Start", draft-agl-tls-snapstart-00 (work in progress), June 2010. [I-D.bmoeller-tls-falsestart] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", draft-bmoeller-tls-falsestart-00 (work in progress), June 2010. [I-D.ietf-core-coap] Frank, B., Bormann, C., Hartke, K., and Z. Shelby, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-08 (work in progress), October 2011. [I-D.mcgrew-tls-aes-ccm] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm-03 (work in progress), February 2012. Hartke & Bergmann Expires September 7, 2012 [Page 7] Internet-Draft Constrained DTLS March 2012 [I-D.moskowitz-hip-rg-dex] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-hip-rg-dex-05 (work in progress), March 2011. [I-D.shelby-core-resource-directory] Krco, S. and Z. Shelby, "CoRE Resource Directory", draft-shelby-core-resource-directory-02 (work in progress), October 2011. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, May 2011. [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [Usenix01] Dean, D. and A. Stubblefield, "Using Client Puzzles to Protect TLS", 2001, . Authors' Addresses Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63905 Fax: +49-421-218-7000 Email: hartke@tzi.org Hartke & Bergmann Expires September 7, 2012 [Page 8] Internet-Draft Constrained DTLS March 2012 Olaf Bergmann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63904 Fax: +49-421-218-7000 Email: bergmann@tzi.org Hartke & Bergmann Expires September 7, 2012 [Page 9]