idnits 2.17.00 (12 Aug 2021) /tmp/idnits31780/draft-fossati-tls-iot-optimizations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-dice-profile has been published as RFC 7925 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Fossati 3 Internet-Draft Nokia 4 Intended status: Informational H. Tschofenig 5 Expires: January 9, 2017 ARM 6 N. Mavrogiannopoulos 7 Red Hat 8 July 8, 2016 10 TLS/DTLS Optimizations for Internet of Things Deployments 11 draft-fossati-tls-iot-optimizations-00 13 Abstract 15 Internet protocols work well in a variety of environments, including 16 Internet of Things (IoT) deployments. While there are some 17 optimization possibilities to reduce code size, bandwidth 18 utilization, and to improve battery lifetime, in general most 19 Internet protocols are also applicable to constrained environments. 20 TLS and DTLS are two such security protocols that can be used by many 21 IoT devices since DTLS/TLS provide lot of flexiblity in terms 22 credential choice, ciphersuite usage, etc. The DICE working group 23 has developed a specification that profiles the use of TLS and DTLS 24 for IoT environments, without changing the TLS/DTLS specifications. 26 This memo goes a step further and proposes changes to the DTLS/TLS 27 protocol to introduce further optimizations. Since the ongoing work 28 on TLS/DTLS 1.3 already offers several improvements (compared to 29 previous versions) this document focuses on the use of version 1.3 30 and suggests further optimizations. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 9, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. Selective Fragment Retransmission . . . . . . . . . . . . . . 3 69 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 70 3.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Transport Agnostic Security Associations . . . . . . . . . . 4 72 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 73 4.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Reducing the DTLS Record Layer Header Overhead . . . . . . . 6 75 5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 76 5.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6. Reducing Buffers . . . . . . . . . . . . . . . . . . . . . . 6 78 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 79 6.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 9.2. Informative References . . . . . . . . . . . . . . . . . 7 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 Internet protocols work well in a variety of environments, including 90 Internet of Things (IoT) deployments. While there are some 91 optimization possibilities to reduce code size, bandwidth 92 utilization, and to improve battery lifetime, in general most 93 Internet protocols are also applicable to constrained environments. 94 TLS and DTLS are two such security protocols that can be used by many 95 IoT devices since DTLS/TLS provide lot of flexiblity in terms 96 credential choice, ciphersuite usage, etc. The DICE working group 97 has developed a specification that profiles the use of TLS and DTLS 98 for IoT environments, without changing the TLS/DTLS specifications. 100 This memo goes a step further and proposes changes to the DTLS/TLS 101 protocol to introduce further optimizations. Since the ongoing work 102 on TLS/DTLS 1.3 [I-D.ietf-tls-tls13] already offers several 103 improvements (compared to previous versions) this document focuses on 104 the use of version 1.3 and suggests further optimizations. 106 This document discusses four extensions, namely: 108 Selective Fragment Retransmission: This extension improves 109 retransmissions of lost handshake packets. 111 Transport Agnostic Security Associations: Changes to a connection 112 (such as an IP address change) requires a new handshake. This 113 extension introduces a transport independent identifier. 115 Reducing the DTLS Record Layer Header Overhead: This extension 116 changes the record layer format to reduce the overhead. 118 Reducing Buffers: This extension allows a DTLS/TLS server running on 119 a constrained node to indicate its buffer size. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 3. Selective Fragment Retransmission 129 3.1. Problem Statement 131 The unit of retransmission used by the DTLS handshake is a whole 132 flight (see Section 4.2.4 of [RFC6347]. If the underlying media is 133 inherently lossy, or shows high latency variance that might fire 134 spurious retransmission, a single fragment that gets lost or is 135 excessively delayed will force the whole flight to be retransmitted. 137 This is further exacerbated when the effective MTU is very low and 138 therefore handshake messages have higher probability to be 139 fragmented. For example, IEEE 802.15.4 networks have a 128-byte MTU 140 size. In such an environment a very "ordinary" 141 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA negotiation can take up to 30 142 individual fragments, 2/3 of which are sent in flight 4. The loss of 143 a single fragment in flight 4 implies a retransmission that is 20x 144 the magnitude of the original loss. 146 The retransmission timer settings suggested in Section 11 of 147 [I-D.ietf-dice-profile] offer mitigation for the spurious retransmit 148 issue and, in general, help with congestion. However, they do not 149 solve the retransmission of the entire flight. 151 3.2. Proposal 153 A potential solution is to add a NACK-based retransmission scheme to 154 the DTLS handshake and the granularity of retransmission would be a 155 message fragment. We note that each fragment in a DTLS handshake is 156 effectively associated to a unique identifier defined by the tuple 157 Handshake.{message_seq,fragment_offset,fragment_length} that can be 158 used in the NACK report to identify the exact geometry of the missing 159 data in the current flight, together with the right-most received 160 byte. 162 4. Transport Agnostic Security Associations 164 4.1. Problem Statement 166 In DTLS, the security context demultiplexing is done via the 5-tuple. 167 This implies that the associated DTLS context needs to be re- 168 negotiated from scratch whenever the IP address changes. For 169 example, when moving the network attachment from WLAN to a cellular 170 connection, or when the IP address of the IoT devices changes during 171 a sleep cyle. A NAT device may also modify the source UDP port after 172 an idle period. In such situations, there is not enough information 173 in the DTLS record header for a DTLS server, which handles multiple 174 clients, to associate the changed address to an existing client. 176 4.2. Proposal 178 A potential solution is to add the ability to negotiate, at handshake 179 time, a transport independent identifier that is unique per security 180 association. We call this identifier the 'Connection ID (CID)' in 181 Figure 1. It decouples the DTLS session from the underlying 182 transport protocol allowing the same DTLS security association to be 183 migrated across different transport sessions. 185 00 186 /\ 187 : 188 IP UDP : DTLS Record Header 189 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 190 | src | dst | proto | | src | dst | : | Seq#i | CID | ... 191 +-----+-----+-------+ +-----+-----+ : +---------+-------+------ 192 `----------------+----------------' : ^ 193 `................ : .............' 194 : 195 GSM-SMS : DTLS Record Header 196 +-------+-------+ : +---------+-------+----- 197 | tp-oa | tp-da | : | Seq#i+1 | CID | ... 198 +-------+-------+ : +---------+-------+----- 199 : 200 \/ 201 00 203 Figure 1: Transparent Handover of DTLS Session 205 That approach modifies the DTLS record layer header to the format 206 described in Figure 2. 208 struct { 209 ContentType type; 210 ProtocolVersion version; 211 uint16 epoch; 212 uint48 sequence_number; 213 uint32 connection_id; // New field 214 uint16 length; 215 opaque fragment[DTLSPlaintext.length]; 216 } DTLSPlaintext; 218 Figure 2: Modified DTLS Record Format 220 A similar approach to support transparent handover of a DTLS session 221 has been described in [I-D.barrett-mobile-dtls] and [Seggelmann]. 223 The privacy issue associated with the use of a long-term identifier 224 must be taken into consideration. For example, client and server 225 could use a hash chain [Lamport] derived from the shared secret and 226 pick the next unused id on handover. 228 5. Reducing the DTLS Record Layer Header Overhead 230 5.1. Problem Statement 232 The DTLS record layer header adds 13 bytes of overhead, as described 233 in Appendix B of [I-D.ietf-dice-profile]. While some of the 234 information carried in the header is unavoidable, other parameters 235 are redundant and included for backwards compatibility reasons. This 236 burden becomes quite substantial in networks with small frame sizes 237 (e.g., low power wide area networks). 239 Overhead that is not strictly needed could be removed to allow 240 applications to transmit more data in a single packet or to make 241 space for other DTLS features, such as the proposal described in 242 Section 4. 244 5.2. Proposal 246 It is possible to at least remove the following parameters in the 247 header: 249 o Protocol Version (2 bytes) 251 o The sequence number component of the nonce_explicit field at the 252 AES-CCM layer is an exact copy of the sequence number in the 253 record layer header field. This leads to a duplication of 8-bytes 254 per record. 256 6. Reducing Buffers 258 6.1. Problem Statement 260 The Maximum Fragment Length extension [RFC6066] allows a client with 261 limited buffer space to specify a different (smaller) maximum size 262 for fragments that the server is allowed to send. The mechanism is 263 not symmetrical: a server cannot state their buffer size. The 264 assumption made in [RFC6066] is that the server is never going to be 265 a constrained device, and therefore does not need such a capability. 266 This may be true for many IoT deployments where the TLS client is 267 implemented in an IoT device that connects to a server on the 268 Internet that does not have memory limitations, such as a server in 269 the cloud. However, with the desire to also deploy CoAPS and HTTPS- 270 based servers in IoT devices, a constrained node may also need to run 271 a DTLS/TLS server. In such a scenario, allowing a constrained server 272 to advertise its Maximum Fragment Length helps to lower memory 273 requirements. 275 6.2. Proposal 277 The semantics of the max_fragment_length extension could be modified 278 to allow the server as well as the client to express their buffer 279 sizes. 281 7. Acknowledgements 283 We would like to thank Stephen Farrell for suggesting the use of hash 284 chains to implement a privacy-friendly connection id. 286 8. Security Considerations 288 This document suggests various extensions to DTLS/TLS and each of 289 them comes with their own security and privacy considerations. Since 290 this version of the document only suggests strawman proposals further 291 discussions are needed to specify the details. 293 9. References 295 9.1. Normative References 297 [I-D.ietf-tls-tls13] 298 Rescorla, E., "The Transport Layer Security (TLS) Protocol 299 Version 1.3", draft-ietf-tls-tls13-13 (work in progress), 300 May 2016. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 308 Extensions: Extension Definitions", RFC 6066, 309 DOI 10.17487/RFC6066, January 2011, 310 . 312 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 313 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 314 January 2012, . 316 9.2. Informative References 318 [I-D.barrett-mobile-dtls] 319 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 320 mobile-dtls-00 (work in progress), March 2009. 322 [I-D.ietf-dice-profile] 323 Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the 324 Internet of Things", draft-ietf-dice-profile-17 (work in 325 progress), October 2015. 327 [Lamport] Lamport, L., "Password Authentication with Insecure 328 Communication", Commun. ACM, 1981. 330 [Seggelmann] 331 Seggelmann, R., Tuexen, M., and E. Rathgeb, "DTLS 332 Mobility", ICDCN 12, 2012. 334 Authors' Addresses 336 Thomas Fossati 337 Nokia 338 Cambridge 339 UK 341 Email: thomas.fossati@nokia.com 343 Hannes Tschofenig 344 ARM 345 Cambridge 346 UK 348 Email: hannes.tschofenig@arm.com 350 Nikos Mavrogiannopoulos 351 Red Hat 352 Brno 353 Czech Republic 355 Email: nmav@redhat.com