idnits 2.17.1 draft-hartke-core-codtls-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 709, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-06) exists of draft-bormann-6lowpan-ghc-04 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-08 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-03) exists of draft-ietf-lwig-guidance-01 == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-11 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-03 == Outdated reference: A later version (-04) exists of draft-mcgrew-tls-aes-ccm-03 == Outdated reference: A later version (-08) exists of draft-mcgrew-tls-aes-ccm-ecc-02 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft O. Bergmann 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: January 17, 2013 July 16, 2012 7 Datagram Transport Layer Security in Constrained Environments 8 draft-hartke-core-codtls-02 10 Abstract 12 This draft considers some obstacles in implementing Datagram 13 Transport Layer Security (DTLS) in constrained environments, and 14 presents some ideas for a constrained version of DTLS that is 15 friendly to constrained nodes and networks. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 17, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Potential Problems and Possible Solutions . . . . . . . . . . 4 56 2.1. Handshake Message Fragmentation . . . . . . . . . . . . . 4 57 2.2. Timer Values . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.3. Connection Initiation . . . . . . . . . . . . . . . . . . 7 59 2.4. Connection Closure . . . . . . . . . . . . . . . . . . . . 9 60 2.5. Application Data Fragmentation . . . . . . . . . . . . . . 9 61 2.6. Data size . . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.7. Code size . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3. Stateless Header Compression . . . . . . . . . . . . . . . . . 12 64 3.1. Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2. Handshake Messages . . . . . . . . . . . . . . . . . . . . 13 66 4. RESTful DTLS Handshake . . . . . . . . . . . . . . . . . . . . 15 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 73 Appendix A. Templates . . . . . . . . . . . . . . . . . . . . . . 20 74 A.1. secp256r1 . . . . . . . . . . . . . . . . . . . . . . . . 20 75 A.2. secp384r1 . . . . . . . . . . . . . . . . . . . . . . . . 21 76 A.3. secp521r1 . . . . . . . . . . . . . . . . . . . . . . . . 22 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 79 1. Introduction 81 1.1. Background 83 Nodes that take part in the "Internet of Things" often have strict 84 limitations regarding their computational power, memory size (both 85 ROM and RAM), and power management [I-D.ietf-lwig-guidance]. Network 86 communication, especially wireless, also imposes constraints that 87 need to be considered during protocol design, e.g. low bitrate, 88 variable delay and possibly high packet loss. Moreover, frames at 89 the link layer might be much smaller than the IPv6 minimum MTU of 90 1280 bytes and therefore require additional mapping mechanisms such 91 as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks 92 [IEEE.802-15-4], which in turn may exacerbate the limitations of the 93 network: E.g., as high loss rates are anticipated by design, 94 application protocols usually try to avoid fragmentation at the 95 network layer. 97 However, application protocols often delegate security mechanisms to 98 transport layer security protocols. More often than not, the 99 protocol overhead from securing the communication is highly relevant 100 to the overall performance of the systems. 102 One protocol that has received significant attention recently for 103 constrained node/network applications is Datagram Transport Layer 104 Security (DTLS) [RFC6347]. DTLS is derived from and inherits some 105 characteristics from TLS [RFC5246]. Although DTLS has not been 106 designed with constrained nodes/networks in mind, it is thought to be 107 usable in such environments [SOS12]. Still, there are a few 108 challenges when it comes to implement DTLS. 110 1.2. Overview 112 The present document considers some obstacles in implementing DTLS in 113 constrained environments, and presents a few ideas to make DTLS more 114 friendly to constrained nodes and networks. 116 The ideas generally fall into one of the following categories: 118 Implementation guidance: Implementation techniques for achieving 119 light-weight implementations of DTLS, without affecting 120 conformance to the relevant specifications or interoperability 121 with other implementations. This includes techniques for reducing 122 complexity, memory footprint, or power usage. The result may 123 eventually be incorporated into [I-D.ietf-lwig-guidance]. 125 Protocol profile: Use of DTLS in a particular way, for example, by 126 changing MAYs into MUSTs or MUST NOTs, or by requiring or 127 precluding certain extensions or cipher suites. Existing DTLS 128 implementations ought to continue to be used without change if 129 they can be configured accordingly. 131 Stateless header compression: Compression of DTLS records without 132 explicitly building any compression context state. This is done 133 by using shorter forms to represent the same bits of information 134 or relying on information that is already shared by the client and 135 server. Existing DTLS implementations can continue to be used if 136 a thin layer is added that handles compression/decompression. 138 Breaking changes: New implementations are required that do not 139 interoperate with implementations of DTLS. 141 1.3. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 (Note that this document itself is informational, but it is 147 discussing normative statements.) 149 The term "byte" is used in its now customary sense as a synonym for 150 "octet". 152 2. Potential Problems and Possible Solutions 154 2.1. Handshake Message Fragmentation 156 DTLS records can be large in size for a single 6LoWPAN [RFC4944] 157 payload: [IEEE.802-15-4] specifies a physical layer MTU of only 127 158 bytes, which yields about 60-80 bytes of payload after adding MAC 159 layer and adaptation layer headers. Although 6LoWPAN supports the 160 fragmentation of IPv6 packets into small link-layer frames, this 161 doesn't really work well for constrained applications and networks. 163 DTLS offers fragmentation at the handshake layer and hence can get 164 around IP fragmentation. However, this can add a significant 165 overhead on the number of datagrams and bytes transferred (see 166 Table 1). Packet loss is also still a big problem for the 167 constrained nodes; buffers must be large enough to hold all messages 168 after reassembly and losing a single fragment will cause all 169 fragments of a message flight to be retransmitted. This is very 170 likely especially during key and certificate exchange as these will 171 not fit within a packet without fragmentation in most 6LoWPANs. 173 +--------------+-----------------+------------------+---------------+ 174 | UDP data | Number of | Total number of | Proportion of | 175 | size limit | datagrams | bytes | header data | 176 | (bytes) | transferred | transferred | | 177 +--------------+-----------------+------------------+---------------+ 178 | 50 | 27 | 1,182 | 55 % | 179 | 55 | 21 | 1,037 | 49 % | 180 | 60 | 20 | 1,081 | 51 % | 181 | 65 | 18 | 1,003 | 47 % | 182 | 70 | 15 | 912 | 42 % | 183 | 75 | 14 | 875 | 39 % | 184 | 80 | 13 | 874 | 39 % | 185 | 85 | 12 | 849 | 37 % | 186 | 90 | 12 | 849 | 37 % | 187 | 1,152 | 6 | 802 | 34 % | 188 +--------------+-----------------+------------------+---------------+ 190 Table 1: Number of datagrams and bytes transferred using different 191 limits for DTLS fragmentation in an example DTLS handshake 192 (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 with raw public key certificate) 194 Possible Solutions include: 196 o Use IP fragmentation instead of DTLS fragmentation. If no X.509 197 certificates are involved, the handshake messages of one flight 198 typically require less than 400 bytes combined. Since all 199 messages of a flight are retransmitted anyway when a single 200 fragment is lost, the difference between performing the 201 fragmentation at the DTLS layer and at the IP layer is probably 202 not huge. A recipient must still be prepared to receive 203 arbitrarily fragmented handshake messages at the DTLS layer, 204 though. 206 o Reduce the number of bytes to be transferred, so the overhead of 207 header data becomes smaller when fragmenting for small packet 208 sizes, and fewer packets need to be transmitted that could 209 potentially be lost: 211 * Use an out-of-band mechanism to exchange large blobs. For 212 example, the TLS Cached Information Extension 213 [I-D.ietf-tls-cached-info] allows to omit the exchange of 214 fairly static information, such as the server certificate, if 215 this information is already available. 217 * Use 6LoWPAN General Header Compression 218 [I-D.bormann-6lowpan-ghc] to compress DTLS messages, as 219 proposed in [DCOSS12]. 221 * Use some DTLS-specific kind of Stateless Header Compression, as 222 shown in Section 3. This can significantly reduce the number 223 of datagrams and bytes transferred, and in particular also the 224 proportion of header data in the number of bytes transferred 225 (see Table 2). 227 * Use compressed point formats for elliptic curve points. 229 * Use self-delimiting numeric values [RFC6256] instead of fixed- 230 size numeric values. 232 * Use a bit field instead of multiple type fields to indicate 233 which handshake messages are present in a datagram. 235 o Perform the DTLS handshake over another protocol, for example, 236 CoAP [I-D.ietf-core-coap] with its support for block-wise 237 transfers [I-D.ietf-core-block], as shown in Section 4. 239 +--------------+-----------------+------------------+---------------+ 240 | UDP data | Number of | Total number of | Proportion of | 241 | size limit | datagrams | bytes | header data | 242 | (bytes) | transferred | transferred | | 243 +--------------+-----------------+------------------+---------------+ 244 | 50 | 15 (56 %) | 592 (50 %) | 10 % | 245 | 55 | 13 (62 %) | 585 (56 %) | 9 % | 246 | 60 | 13 (65 %) | 621 (57 %) | 14 % | 247 | 65 | 11 (61 %) | 588 (59 %) | 10 % | 248 | 70 | 11 (73 %) | 573 (63 %) | 7 % | 249 | 75 | 11 (79 %) | 573 (65 %) | 7 % | 250 | 80 | 10 (77 %) | 567 (65 %) | 6 % | 251 | 85 | 10 (83 %) | 567 (67 %) | 6 % | 252 | 90 | 10 (83 %) | 567 (67 %) | 6 % | 253 | 1,152 | 6 (100 %) | 617 (77 %) | 14 % | 254 +--------------+-----------------+------------------+---------------+ 256 Table 2: Number of datagrams and bytes transferred in the same 257 example DTLS handshake but using Stateless Header Compression 258 (Section 4) 260 2.2. Timer Values 262 DTLS leaves the choice of timer values to the implementation, but 263 makes the following recommendation: 265 "Implementations SHOULD use an initial timer value of 1 second 266 (the minimum defined in RFC 6298 [RFC6298]) and double the value 267 at each retransmission, up to no less than the RFC 6298 maximum of 268 60 seconds." [RFC6347] 270 Given the time required by some algorithms when executed on a 271 constrained devices (see Table 3), an initial value of 1 second can 272 easily lead to spurious retransmissions. 274 +-------------+--------------+-----------+------------+-------------+ 275 | Algorithm | Library | Memory | Execution | Comparable | 276 | | | footprint | time | RSA key | 277 | | | (bytes) | (seconds) | length | 278 +-------------+--------------+-----------+------------+-------------+ 279 | RSA 1024 | AvrCryptolib | 640 | 199.7 | | 280 | RSA 2048 | AvrCryptolib | 1,280 | 1,587.6 | | 281 | ECDSA 160r1 | TinyECC | 892 | 2.3 | 1024 | 282 | ECDSA 192r1 | TinyECC | 1,008 | 3.6 | 1536 | 283 | ECDSA 160r1 | Wiselib | 842 | 20.2 | 1024 | 284 | ECDSA 192r1 | Wiselib | 952 | 34.6 | 1536 | 285 | ECDSA 163k1 | Relic | 2,804 | 0.3 | 1024 | 286 | ECDSA 233k1 | Relic | 3,675 | 1.8 | 2048 | 287 +-------------+--------------+-----------+------------+-------------+ 289 Table 3: RSA private key operation and ECDSA signature performance 290 (from [I-D.aks-crypto-sensors]) 292 Possible Solutions include: 294 o Adjust the timer value to meet the conditions of constrained nodes 295 and low-power, lossy networks. 297 o Add some kind of acknowledgment message to DTLS that allows an 298 implementation to confirm the receipt of a message before 299 preparing the next message flight. 301 2.3. Connection Initiation 303 Nodes with very constrained main memory also suffer from the 304 complexity of the DTLS handshake protocol. We envision that the 305 acceptance of DTLS as security protocol for embedded devices would 306 significantly increase if a less complex connection initiation 307 procedure with a smaller number of handshake messages was defined. 309 Compared to TLS, DTLS exacerbates the connection initiation: A DTLS 310 handshake has an additional roundtrip that results from the addition 311 of a stateless cookie exchange. This exchange is designed to prevent 312 certain denial-of-service attacks: consumption of excessive server 313 resources caused by the transmission of a series of handshake 314 initiation requests, and use of the server as an amplifier by sending 315 connection initiation messages with a forged source of the victim. 317 Possible Solutions include: 319 o Create the DTLS connection before it is needed, so it doesn't take 320 a long time to set it up when it's actually needed. This works if 321 a server has do deal with a relatively small overall number of 322 clients that wish to interact with the server. Care must be taken 323 such that not all clients perform their handshake at the same 324 time, as a handshake requires considerably more memory than 325 keeping a connection open. (See also Section 2.4 below.) 327 o Shorten the handshake to four flights. This may be possible 328 without losing the denial-of-service roundtrip if the cipher suite 329 permits that the server remains stateless after sending the 330 ServerHello and if the flight fits in one datagram (see Figure 1). 332 Client Server 333 ------ ------ 335 ClientHello --------> Flight 1 337 HelloVerifyRequest \ 338 ServerHello Flight 2 339 <-------- ServerHelloDone / 340 (remain stateless) 342 ClientHello \ 343 "ServerHello" \ 344 ClientKeyExchange Flight 3 345 [ChangeCipherSpec] / 346 Finished --------> / 348 [ChangeCipherSpec] \ Flight 4 349 <-------- Finished / 351 Figure 1: Artist's impression of a four-flight DTLS handshake with 352 Pre-Shared Key 354 o As an alternative, client puzzles could be used as a mechanism for 355 mitigating denial-of-service attacks, resulting in a four-flight 356 exchange similar to the one in HIP DEX [I-D.moskowitz-hip-rg-dex]. 357 The application of client puzzles to TLS has been shown 358 [USENIX01]. However, a puzzle would be needed that ideally takes 359 less effort for a constrained device and more effort for a less 360 constrained device. 362 2.4. Connection Closure 364 Although a connection needs considerably less memory after a 365 handshake has finished, it still requires, e.g., around 80 bytes with 366 AES-128-CCM [I-D.mcgrew-tls-aes-ccm] for the keys, sequence numbers 367 and anti-replay window. More memory is needed if session resumption 368 is supported, to keep the 48-byte master secret and negotiated 369 connection parameters. This limits how many connections a 370 constrained device can maintain at a given time. Often, constrained 371 devices will have a fixed number of "slots" for connections rather 372 than allocating memory dynamically for each connection. 374 DTLS provides a facility for secure connection closure. When a valid 375 closure alert is received, an implementation can be assured that no 376 further data will be received on that connection. It is noteworthy, 377 though, that the closure alert is not a handshake message and thus is 378 not retransmitted when packet loss occurs. 380 Possible Solutions include: 382 o Maintain the session for as long as possible. When the server 383 runs out of resources, it can close connections, e.g., using a 384 Least Frequently Used (LFU) eviction policy. The client simply 385 assumes that the connection is active until the server rejects its 386 application data, in which case the client initiates a new 387 connection. 389 o Use the DTLS Heartbeat Extension [RFC6520] to figure out from time 390 to time if the connection is still active. 392 2.5. Application Data Fragmentation 394 Messages larger than an IP fragment result in undesired packet 395 fragmentation. DTLS does not support fragmentation of application 396 data. If an implementation of an application layer protocol such as 397 CoAP [I-D.ietf-core-coap] wants to avoid IP fragmentation, it must 398 fit the application data (e.g., a CoAP message) and all headers 399 within a single IP packet. 401 DTLS has a per-record overhead of 13 bytes for the record header. 402 AEAD ciphers such as AES-CCM [I-D.mcgrew-tls-aes-ccm] eat up 403 additional space to carry the explicit nonce and the authentication 404 tag. Thus, cipher suites like TLS_PSK_WITH_AES_128_CCM_8 or 405 TLS_ECDHE_ECDSA_AES_128_CCM_8 requires 16 additional bytes, leading 406 to an overall overhead of 29 bytes for the header of each encrypted 407 DTLS packet. With packet sizes of 60-80 bytes, this takes a 408 considerable portion of the available packet size away (see Table 4). 410 +------------------+------------------------+-----------------------+ 411 | UDP data size | Number of bytes left | ... with Stateless | 412 | limit (bytes) | for application data | Header Compression | 413 +------------------+------------------------+-----------------------+ 414 | 50 | 21 (42 %) | 39 (78 %) | 415 | 55 | 26 (47 %) | 44 (80 %) | 416 | 60 | 31 (52 %) | 49 (82 %) | 417 | 65 | 36 (55 %) | 54 (83 %) | 418 | 70 | 41 (59 %) | 59 (84 %) | 419 | 75 | 46 (61 %) | 64 (85 %) | 420 | 80 | 51 (64 %) | 69 (86 %) | 421 | 85 | 56 (66 %) | 74 (87 %) | 422 | 90 | 61 (68 %) | 79 (88 %) | 423 | 1,152 | 1,123 (97 %) | 1,141 (99 %) | 424 +------------------+------------------------+-----------------------+ 426 Table 4: Number of bytes left for data in an ApplicationData record 427 using DTLS and DTLS with Stateless Header Compression (Section 4) 429 Possible Solutions include: 431 o Elide the GenericAEADCipher.nonce_explicit field when AES-CCM is 432 used. The GenericAEADCipher.nonce_explicit field is set to the 433 16-bit epoch concatenated with the 48-bit sequence number, which 434 means that the epoch and sequence number are unnecessarily 435 included twice in each record. 437 o Elide the DTLS version field where it is implicitly clear. Since 438 the DTLS version is negotiated in the handshake, there should not 439 be a need to specify the DTLS version in each and every record. 441 o Elide the length field of the last record in a datagram. DTLS 442 records specify their length so multiple records can be 443 transmitted in a single datagram. When DTLS is used with UDP 444 (which preserves the boundaries of all message sent), the length 445 field of the last record in a datagram can be calculated from the 446 UDP payload length. 448 For example, when using the Stateless Header Compression presented in 449 Section 3 and eliminating the redundant epoch and sequence number 450 information, the number of bytes left in an ApplicationData record 451 for application data can be significantly increased (see Table 4). 453 2.6. Data size 455 As fragmented handshake messages can arrive at a constrained node in 456 any order, the receiver must provide a message buffer that is large 457 enough to hold multiple fragments. When several handshake messages 458 forming a single flight are sent out in parallel, it is likely that 459 the receiver's resources are too limited to order fragments from 460 distinct handshake messages. Avoiding this might require additional 461 resources on the server side to ensure serialization of a flight's 462 messages. 464 Furthermore, since handshake messages can be fragmented arbitrarily 465 and with overlaps, the receiver must, in addition to the message 466 buffer, keep track of the fragments received so far. 468 Possible retransmissions require even more buffer space as replay- 469 protection requires encryption of every single packet that is to be 470 transmitted. In particular, this renders destructive in-place 471 encryption impossible as the source data must be preserved. 473 Possible Solutions include: 475 o Use the same sequence number when retransmitting a message, so the 476 plaintext could be encrypted in-place without the need for a 477 second buffer. The security implications of this change need to 478 be carefully analyzed. 480 o Favour cryptographic algorithms that use less memory, possibly 481 resulting in a slower performance. 483 o Add some kind of acknowledgment message to DTLS that allows an 484 receiver to confirm the receipt of a message, and let the sender 485 wait for the acknowledgment before it sends the next part of the 486 flight. 488 2.7. Code size 490 Although probably not as severe as data size limits, the code size of 491 a DTLS implementation also can play a role, in particular for 492 constrained devices at the lower bound of Class 1 devices. 494 Possible Solutions include: 496 o Avoid static tables for cryptographic functions where possible, as 497 typical embedded platforms are more restricted in RAM than in non- 498 volatile memory such as flash ROM. Instead, their procedural 499 equivalent is to be used, although less efficient during run-time. 501 o Use using pre-composed messages instead of writing code, e.g., for 502 encoding or decoding ASN.1 structures, as shown in Appendix A. 504 3. Stateless Header Compression 506 Stateless Header Compression compresses the headers of records and 507 handshake messages. The compression is lossless, does not increase 508 the record length and is done without explicitly building any 509 compression context state. 511 The Finished MAC is computed as if each handshake message had been 512 sent uncompressed. 514 3.1. Records 516 Records are compressed by specifying the type, version, epoch, 517 sequence_number and length fields using a variable number of bytes. 518 A prefix is added in front of the structure to indicate the length of 519 each field or to specify the value of the field directly. If the 520 value is specified directly, the field itself is elided. The format 521 of the prefix is as follows: 523 0 1 524 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |0| T | V | E |1 1 0| S | L | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 The fields in the prefix are defined as follows: 531 T: Describes the type field. 533 0 - Content Type 20 (ChangeCipherSpec) 534 1 - 8-bit type field 535 2 - Content Type 22 (Handshake) 536 3 - Content Type 23 (Application Data) 538 V: Describes the version field. 540 0 - Version 254.255 (DTLS 1.0) 541 1 - 16-bit version field 542 2 - Version 254.253 (DTLS 1.2) 543 3 - Reserved for future use 545 E: Describes the epoch field. 547 0 - Epoch 0 548 1 - Epoch 1 549 2 - Epoch 2 550 3 - Epoch 3 551 4 - Epoch 4 552 5 - 8-bit epoch field 553 6 - 16-bit epoch field 554 7 - Implicit -- same as previous record in the datagram 556 S: Describes the sequence_number field. 558 0 - Sequence number 0 559 1 - 8-bit sequence_number field 560 2 - 16-bit sequence_number field 561 3 - 24-bit sequence_number field 562 4 - 32-bit sequence_number field 563 5 - 40-bit sequence_number field 564 6 - 48-bit sequence_number field 565 7 - Implicit -- number of previous record in the datagram + 1 567 L: Describes the length field. 569 0 - Length 0 570 1 - 8-bit length field 571 2 - 16-bit length field 572 3 - Implicit -- last record in the datagram 574 3.2. Handshake Messages 576 Handshake messages are compressed in a similar way. A prefix is 577 added in front of the structure to indicate the length of each field 578 or to specify the value of the field directly. If the value is 579 specified directly, the field itself is elided. The format of the 580 prefix is as follows: 582 0 1 583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |0 0| T | L | S | O | C | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 The fields in the prefix are defined as follows: 590 T: Describes the msg_type field. 592 0 - 8-bit msg_type field 593 1 - Handshake Type 1 (Client Hello) 594 2 - Handshake Type 2 (Server Hello) 595 3 - Handshake Type 3 (Hello Verify Request) 596 4 - Reserved for future use 597 5 - Reserved for future use 598 6 - Reserved for future use 599 7 - Handshake Type 11 (Certificate) 600 8 - Handshake Type 12 (Server Key Exchange) 601 9 - Handshake Type 13 (Certificate Request) 602 10 - Handshake Type 14 (Server Hello Done) 603 11 - Handshake Type 15 (Certificate Verify) 604 12 - Handshake Type 16 (Client Key Exchange) 605 13 - Reserved for future use 606 14 - Reserved for future use 607 15 - Handshake Type 20 (Finished) 609 L: Describes the length field. 611 0 - Implicit -- last message in the record 612 1 - 8-bit length field 613 2 - 16-bit length field 614 3 - 24-bit length field 616 S: Describes the message_seq field. 618 0 - Message sequence number 0 619 1 - Message sequence number 1 620 2 - Message sequence number 2 621 3 - Message sequence number 3 622 4 - Message sequence number 4 623 5 - Message sequence number 5 624 6 - Message sequence number 6 625 7 - Message sequence number 7 626 8 - Message sequence number 8 627 9 - Message sequence number 9 628 10 - Message sequence number 10 629 11 - Message sequence number 11 630 12 - Message sequence number 12 631 13 - 8-bit message_seq field 632 14 - 16-bit message_seq field 633 15 - Implicit -- number of previous message in the record + 1 635 O: Describes the fragment_offset field. 637 0 - Offset 0 638 1 - 8-bit fragment_offset field 639 2 - 16-bit fragment_offset field 640 3 - 24-bit fragment_offset field 642 C: Describes the fragment_length field. 644 0 - Implicit -- last message in the record 645 1 - 8-bit fragment_length field 646 2 - 16-bit fragment_length field 647 3 - 24-bit fragment_length field 649 4. RESTful DTLS Handshake 651 Where DTLS is used in conjunct with the Constrained Application 652 Protocol (CoAP) [I-D.ietf-core-coap], it might be beneficial to use 653 CoAP with its support for block-wise transfers [I-D.ietf-core-block] 654 instead of DTLS's convoluted handshake protocol to transport DTLS 655 handshake messages. 657 CoAP, like HTTP, is designed for applications following the REST 658 architectural style [REST]. So the DTLS connection is modeled as a 659 CoAP resource which gets created when a client wants to initiate a 660 connection, and gets updated to modify the state and parameters of 661 the connection. A well-known URI path [RFC5785] is used to identify 662 a collection resource that models the set of active connections and 663 allows new connections to be created. 665 Client Server 666 ------ ------ 668 POST /.well-known/dtls 669 ClientHello -----> 671 1.xx Verify 672 <----- HelloVerifyRequest 674 POST /.well-known/dtls 675 ClientHello -----> 677 2.01 Created /session/4ad6bc29 678 ServerHello 679 Certificate* 680 ServerKeyExchange* 681 CertificateRequest* 682 <----- ServerHelloDone 684 PATCH /session/4ad6bc29 685 Certificate* 686 ClientKeyExchange 687 CertificateVerify* 688 [ChangeCipherSpec] 689 Finished -----> 691 2.04 Changed 692 [ChangeCipherSpec] 693 <----- Finished 695 Figure 2: Message Flights for Full Handshake 697 Client Server 698 ------ ------ 700 PATCH /session/4ad6bc29 701 ClientHello -----> 703 2.04 Changed 704 ServerHello 705 [ChangeCipherSpec] 706 <----- Finished 708 PATCH /session/4ad6bc29 709 [ChangeCipherSpec] 710 Finished -----> 712 <----- 2.04 Changed 714 Figure 3: Message Flights for Session-Resuming Handshake 716 There are the following possible operations: 718 o POST to well-known URI: requests the server to create a new 719 session resource. 721 o PATCH session resource: requests the server to change session 722 parameters, or to resume a session. 724 o GET session resource: returns a representation of the session. 726 o DELETE session resource: requests the server to delete the session 727 resource and free all resources related to the session. 729 The following protocols and URI schemes are used: 731 o CoAP [I-D.ietf-core-coap] 733 o coap+codtls:// 735 The following well-known URIs are used: 737 o /.well-known/dtls 739 The following media types are used: 741 o application/dtls 743 (The exact definition of these items is TBD.) 745 5. Security Considerations 747 Beyond stateless header compression and profiling, changes to the 748 TLS/DTLS protocol need to be performed extremely carefully. No 749 analysis has been done in the present version of this draft. 751 6. IANA Considerations 753 This draft includes no request to IANA. 755 7. Acknowledgements 757 Thanks to Angelo P. Castellani, Stefan Jucker and Shahid Raza for 758 helpful comments and discussions that have shaped the document. 760 8. References 762 8.1. Normative References 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 768 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 770 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 771 Security Version 1.2", RFC 6347, January 2012. 773 8.2. Informative References 775 [DCOSS12] Raza, S., Trabalza, D., and T. Voigt, "6LoWPAN Compressed 776 DTLS for CoAP", 8th IEEE International Conference on 777 Distributed Computing in Sensor Systems, May 2012. 779 [I-D.aks-crypto-sensors] 780 Sethi, M., Arkko, J., Keranen, A., and H. Rissanen, 781 "Practical Considerations and Implementation Experiences 782 in Securing Smart Object Networks", 783 draft-aks-crypto-sensors-02 (work in progress), 784 March 2012. 786 [I-D.bormann-6lowpan-ghc] 787 Bormann, C., "6LoWPAN Generic Compression of Headers and 788 Header-like Payloads", draft-bormann-6lowpan-ghc-04 (work 789 in progress), March 2012. 791 [I-D.ietf-core-block] 792 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 793 draft-ietf-core-block-08 (work in progress), 794 February 2012. 796 [I-D.ietf-core-coap] 797 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 798 "Constrained Application Protocol (CoAP)", 799 draft-ietf-core-coap-10 (work in progress), June 2012. 801 [I-D.ietf-lwig-guidance] 802 Bormann, C., "Guidance for Light-Weight Implementations of 803 the Internet Protocol Suite", draft-ietf-lwig-guidance-01 804 (work in progress), July 2012. 806 [I-D.ietf-tls-cached-info] 807 Santesson, S. and H. Tschofenig, "Transport Layer Security 808 (TLS) Cached Information Extension", 809 draft-ietf-tls-cached-info-11 (work in progress), 810 December 2011. 812 [I-D.ietf-tls-oob-pubkey] 813 Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 814 Tschofenig, "TLS Out-of-Band Public Key Validation", 815 draft-ietf-tls-oob-pubkey-03 (work in progress), 816 April 2012. 818 [I-D.mcgrew-tls-aes-ccm] 819 McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS", 820 draft-mcgrew-tls-aes-ccm-03 (work in progress), 821 February 2012. 823 [I-D.mcgrew-tls-aes-ccm-ecc] 824 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 825 CCM ECC Cipher Suites for TLS", 826 draft-mcgrew-tls-aes-ccm-ecc-02 (work in progress), 827 October 2011. 829 [I-D.moskowitz-hip-rg-dex] 830 Moskowitz, R., "HIP Diet EXchange (DEX)", 831 draft-moskowitz-hip-rg-dex-06 (work in progress), 832 May 2012. 834 [IEEE.802-15-4] 835 "Information technology - Telecommunications and 836 information exchange between systems - Local and 837 metropolitan area networks - Specific requirements - Part 838 15.4: Wireless Medium Access Control (MAC) and Physical 839 Layer (PHY) Specifications for Low-Rate Wireless Personal 840 Area Networks (WPANs)", IEEE Standard 802.15.4, 841 September 2006, . 844 [REST] Fielding, R., "Architectural Styles and the Design of 845 Network-based Software Architectures", Ph.D. Dissertation, 846 University of California, Irvine, 2000, . 850 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 851 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 852 for Transport Layer Security (TLS)", RFC 4492, May 2006. 854 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 855 "Transmission of IPv6 Packets over IEEE 802.15.4 856 Networks", RFC 4944, September 2007. 858 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 859 Uniform Resource Identifiers (URIs)", RFC 5785, 860 April 2010. 862 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 863 Values in Protocols", RFC 6256, May 2011. 865 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 866 "Computing TCP's Retransmission Timer", RFC 6298, 867 June 2011. 869 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 870 Layer Security (TLS) and Datagram Transport Layer Security 871 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 873 [SOS12] Arkko, J. and H. Tschofenig, "Conclusions from the 874 Workshop on Smart Object Security", Workshop on Smart 875 Object Security, March 2012, . 879 [USENIX01] 880 Dean, D. and A. Stubblefield, "Using Client Puzzles to 881 Protect TLS", 10th USENIX Security Symposium, August 2001, 882 . 885 Appendix A. Templates 887 When elliptic curve cryptography is used, building and parsing the 888 bodies of Certificate, ServerKeyExchange and ClientKeyExchange 889 messages mainly involves the encoding and decoding of elliptic curve 890 points. The points are encapsulated in a mix of DTLS structures and 891 ASN.1 sequences. For a given elliptic curve, some parts of a message 892 body are static, which allows using pre-composed messages instead of 893 writing lots of memory consuming code pertaining to DTLS and ASN.1. 895 This appendix provides templates for the bodies of the Certificate, 896 ServerKeyExchange and ClientKeyExchange messages used in a DTLS 897 handshake with raw public key certificates [I-D.ietf-tls-oob-pubkey] 898 and the ECDHE_ECDSA key exchange [RFC4492]. 900 The templates are given for the named curves secp256r1, secp384r1 and 901 secp521r1; these curves are equivalent to the NIST P-256, P-384, and 902 P-521 curves. They are required in [I-D.mcgrew-tls-aes-ccm-ecc]. 903 The same curve is used in each case for both the raw public key 904 certificate and the ephemeral keys. Points are represented in 905 uncompressed point format. 907 Note: The templates have not been independently verified yet. 909 A.1. secp256r1 911 Raw Public Key Certificate: 913 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 914 86 48 ce 3d 03 01 07 03 42 00 04 __ __ __ __ __ 915 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 916 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 917 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 918 __ __ __ __ __ __ __ __ __ __ __ 920 ECDSA-capable public key (x, y) 922 Server Key Exchange: 924 03 00 17 41 04 __ __ __ __ __ __ __ __ __ __ __ 925 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 926 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 927 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 928 __ __ __ __ __ 00 46 30 44 02 20 __ __ __ __ __ 929 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 930 __ __ __ __ __ __ __ __ __ __ __ 02 20 __ __ __ 931 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 932 __ __ __ __ __ __ __ __ __ __ __ __ __ 934 ephemeral ECDH public key (x, y) and ECDSA signature (r, s) 936 Client Key Exchange: 938 41 04 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 939 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 940 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 941 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 942 __ __ 944 ephemeral ECDH public key (x, y) 946 A.2. secp384r1 948 Raw Public Key Certificate: 950 30 76 30 10 06 07 2a 86 48 ce 3d 02 01 06 05 2b 951 81 04 00 22 03 62 00 04 __ __ __ __ __ __ __ __ 952 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 953 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 954 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 955 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 956 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 957 __ __ __ __ __ __ __ __ 959 ECDSA-capable public key (x, y) 961 Server Key Exchange: 963 03 00 18 61 04 __ __ __ __ __ __ __ __ __ __ __ 964 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 965 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 966 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 967 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 968 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 969 __ __ __ __ __ 00 66 30 64 02 30 __ __ __ __ __ 970 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 971 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 972 __ __ __ __ __ __ __ __ __ __ __ 02 30 __ __ __ 973 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 974 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 975 __ __ __ __ __ __ __ __ __ __ __ __ __ 977 ephemeral ECDH public key (x, y) and ECDSA signature (r, s) 979 Client Key Exchange: 981 61 04 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 982 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 983 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 984 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 985 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 986 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 987 __ __ 989 ephemeral ECDH public key (x, y) 991 A.3. secp521r1 993 Raw Public Key Certificate: 995 30 81 9b 30 10 06 07 2a 86 48 ce 3d 02 01 06 05 996 2b 81 04 00 23 03 81 86 00 04 __ __ __ __ __ __ 997 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 998 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 999 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1000 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1001 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1002 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1003 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1004 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1006 ECDSA-capable public key (x, y) 1008 Server Key Exchange: 1010 03 00 19 85 04 __ __ __ __ __ __ __ __ __ __ __ 1011 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1012 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1013 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1014 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1015 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1016 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1017 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1018 __ __ __ __ __ __ __ __ __ 00 8b 30 81 88 02 42 1019 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1020 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1021 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1022 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1023 __ __ 02 42 __ __ __ __ __ __ __ __ __ __ __ __ 1024 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1025 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1026 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1027 __ __ __ __ __ __ 1029 ephemeral ECDH public key (x, y) and ECDSA signature (r, s) 1031 Client Key Exchange: 1033 85 04 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1034 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1035 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1036 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1037 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1038 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1039 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1040 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ 1041 __ __ __ __ __ __ 1043 ephemeral ECDH public key (x, y) 1045 Authors' Addresses 1047 Klaus Hartke 1048 Universitaet Bremen TZI 1049 Postfach 330440 1050 Bremen D-28359 1051 Germany 1053 Phone: +49-421-218-63905 1054 Email: hartke@tzi.org 1056 Olaf Bergmann 1057 Universitaet Bremen TZI 1058 Postfach 330440 1059 Bremen D-28359 1060 Germany 1062 Phone: +49-421-218-63904 1063 Email: bergmann@tzi.org