idnits 2.17.1 draft-ietf-lwig-tls-minimal-01.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 (March 8, 2014) is 3702 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4347' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 616, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-03) exists of draft-gilger-smart-object-security-workshop-02 -- Obsolete informational reference (is this intentional?): RFC 3268 (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group S. Kumar 3 Internet-Draft Philips Research 4 Intended status: Informational S. Keoh 5 Expires: September 9, 2014 University of Glasgow Singapore 6 H. Tschofenig 7 ARM Ltd. 8 March 8, 2014 10 A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol 11 for Smart Objects and Constrained Node Networks 12 draft-ietf-lwig-tls-minimal-01 14 Abstract 16 Transport Layer Security (TLS) is a widely used security protocol 17 that offers communication security services at the transport layer. 18 The initial design of TLS was focused on the protection of 19 applications running on top of the Transmission Control Protocol 20 (TCP), and was a good match for securing the Hypertext Transfer 21 Protocol (HTTP). Subsequent standardization efforts lead to the 22 publication of the Datagram Transport Layer Security (DTLS) protocol, 23 which allows the re-use of the TLS security functionality and the 24 payloads to be exchanged on top of the User Datagram Protocol (UDP). 26 With the work on the Constrained Application Protocol (CoAP), as a 27 specialized web transfer protocol for use with constrained nodes and 28 constrained networks, DTLS is a preferred communication security 29 protocol. 31 Smart objects are constrained in various ways (e.g., CPU, memory, 32 power consumption) and these limitations may impose restrictions on 33 the protocol stack such a device runs. This document only looks at 34 the security part of that protocol stacks and the ability to 35 customize TLS/DTLS. To offer input for implementers and system 36 architects this document illustrates the costs and benefits of 37 various TLS/DTLS features for use with smart objects and constraint 38 node networks. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 9, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Performance Numbers . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. Pre-Shared Key (PSK) based DTLS implementation . . . . . 7 79 4.1.1. Prototype Environment . . . . . . . . . . . . . . . . 7 80 4.1.2. Code size and Memory Consumption . . . . . . . . . . 8 81 4.1.3. Communication Overhead . . . . . . . . . . . . . . . 8 82 4.1.4. Message Delay, Success Rate and Bandwidth . . . . . . 9 83 4.2. Certificate based and Raw-public key based TLS 84 implementation . . . . . . . . . . . . . . . . . . . . . 10 85 4.2.1. Prototype Environment . . . . . . . . . . . . . . . . 10 86 4.2.2. Code size . . . . . . . . . . . . . . . . . . . . . . 10 87 4.2.3. Raw Public Key Implementation . . . . . . . . . . . . 11 88 5. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 12 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 9.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 The IETF published three versions of Transport Layer Security: TLS 100 Version 1.0 [RFC2246], TLS Version 1.1 [RFC4346], and TLS Version 1.2 101 [RFC5246] Section 1.1 of [RFC4346] explains the differences between 102 Version 1.0 and Version 1.1; those are small security improvements, 103 including the usage of an explicit initialization vector to protect 104 against cipher-block-chaining attacks, which all have little to no 105 impact on smart object implementations. Section 1.2 of [RFC5246] 106 describes the differences between Version 1.1 and Version 1.2. TLS 107 1.2 introduces a couple of major changes with impact to size of an 108 implementation. In particular, prior TLS versions hard-coded the MD5 109 and SHA-1 [SHA] combination in the pseudo-random function (PRF). As 110 a consequence, any TLS Version 1.0 and Version 1.1 implementation had 111 to have MD5 and SHA-1 code even if the remaining cryptographic 112 primitives used other algorithms. With TLS Version 1.2 the two had 113 been replaced with cipher-suite-specified PRFs. In addition, the TLS 114 extensions definition [RFC6066] and various AES ciphersuites 115 [RFC3268] got merged into the TLS Version 1.2 specification. 117 All three TLS specifications list a mandatory-to-implement 118 ciphersuite: for TLS Version 1.0 this was 119 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, for TLS Version 1.1 it was 120 TLS_RSA_WITH_3DES_EDE_CBC_SHA, and for TLS Version 1.2 it is 121 TLS_RSA_WITH_AES_128_CBC_SHA. There is, however, an important 122 qualification to these compliance statements, namely that they are 123 only valid in the absence of an application profile standard 124 specifying otherwise. The smart object environment may, for example, 125 represent a situation for such an application profile which defines a 126 cryptosuite that reduces memory and computation requirements without 127 sacrificing security. 129 All TLS versions offer a separation between authentication and key 130 exchange, and bulk data protection. The former is more costly 131 performance- and message-wise. The details of the authentication and 132 key exchange, using the TLS Handshake, vary with the chosen 133 ciphersuite. With new ciphersuites the TLS feature-set can easily be 134 enhanced, in case the already large collection of ciphersuites, see 135 [TLS-IANA], does not match the requirements. 137 Once the TLS Handshake has been successfully completed the necessary 138 keying material and parameters are setup for usage with the TLS 139 Record Layer, which is responsible for bulk data protection. The 140 provided security of the TLS Record Layer depends also, but not only, 141 on the chosen ciphersuite algorithms; NULL encryption ciphersuites, 142 like those specified in [RFC4785], offer only integrity- without 143 confidentiality-protection. Example ciphersuites for the TLS Record 144 Layer are RC4 with SHA-1, AES-128 with SHA-1, AES-256 with SHA-1, RC4 145 with SHA-1, RC4 with MD5 It is worth mentioning that TLS may also be 146 used without the TLS Record Layer. This has, for example, been 147 exercised with the work on the framework for establishing a Secure 148 Real-time Transport Protocol (SRTP) security context using the 149 Datagram Transport Layer Security (DTLS) protocol (DTLS- SRTP 150 [RFC5763]). 152 It is fair to say that TLS and consequently DTLS offers a fair degree 153 of flexibility. What specific security features of TLS are required 154 for a specific smart object application scenario depends on various 155 factors, including the communication architecture and the threats 156 that shall be mitigated. 158 The goal of this document is to provide guidance on how to use 159 existing DTLS/TLS extensions for smart objects and to explain their 160 costs in terms of code size, computational effort, communication 161 overhead, and (maybe) energy consumption. The document does not try 162 to be exhaustive, as the list of TLS/DTLS extensions is enhanced on a 163 frequent basis. Instead we focus on extensions that those working in 164 the smart object community often found valuable in their practical 165 experience. A non-goal is to propose new extensions to DTLS/TLS to 166 provide even better performance characteristics in specific 167 environments. 169 2. Overview 171 A security solution to be deployed is strongly influenced by the 172 communication relationships [RFC4101] between the entities. Having a 173 good understanding of these relationships will be essential to define 174 the threats and decide on how to customize the security solution. 175 Some of these considerations are described in [I-D.gilger-smart- 176 object-security-workshop]. 178 Consider the following scenario where a smart-meter transmits its 179 energy readings to other parties. The public utility has to ensure 180 that the meter readings it obtained can be attributed to a specific 181 meter in a household. It is simply not acceptable for public utility 182 to have any meter readings tampered in transit or by a rogue endpoint 183 (particularly if the attack leads to a disadvantage, for example 184 financial loss, for the utility). Users in a household may want to 185 ensure that only certain authorized parties are able to read their 186 meter; privacy concerns come to mind. 188 In this example, a smart-meter may only ever need to talk to servers 189 of a specific utility or even only to a single pre-configured server. 190 Clearly, some information has to be pre-provisioned into the device 191 to ensure the desired behavior to talk only to selected servers. The 192 meter may come pre-configured with the domain name and certificate 193 belonging to the utility. The device may, however, also be 194 configured to accept one or multiple server certificates. It may 195 even be pre-provisioned with the server's raw public key, or a shared 196 secret instead of relying on certificates. 198 Lowering the flexibility decreases the implementation overhead. If 199 shared secrets are used with TLS-PSK [RFC4279] or raw public keys are 200 used with TLS [I-D.ietf-tls-oob-pubkey], fewer lines of code are 201 needed than employing X.509 certificate, as will be explained later 202 in this document. A decision for constraining the client-side TLS 203 implementation, for example by offering only a single ciphersuite, 204 has to be made in awareness of what functionality will be available 205 on the TLS server-side. In certain communication environments it may 206 be easy to influence both communication partners while in other cases 207 the existing deployment needs to be taken into consideration. 209 To illustrate another example, consider an Internet radio, which 210 allows a user to connect to available radio stations. A device like 211 this will be more demanding than an IP-enabled weighing scale that 212 only connects to the single web server offered by the device 213 manufacturer. A threat assessment may even lead to the conclusion 214 that TLS support is not necessary at all in this particular case. 216 Consider the following extension to our earlier scenario where the 217 smart-meter is attached to a home WLAN network and the inter-working 218 with WLAN security mechanisms need to be taken care of. On top of 219 the link layer authentication, a transport layer or application layer 220 security mechanism needs to be implemented. Quite likely the 221 security mechanisms will be different due to the different credential 222 requirements. While there is a possibility for re-use of 223 cryptographic libraries (such as the SHA-1, MD5, or HMAC) the overall 224 code footprint will very likely be larger. 226 Furthermore, security technology that will be deployed by end-user 227 consumer market products and large enterprise customer products will 228 need to be customized completely different. While the security 229 building blocks may be reused, there is certainly a big difference 230 between in terms of the architecture, the threats and effort that 231 will be spent securing the system. 233 3. Design Decisions 235 To evaluate the required TLS functionality a couple of high level 236 design decisions have to be made: 238 o What type of protection for the data traffic is required? Is 239 confidentiality protection in addition to integrity protection 240 required? Many TLS ciphersuites also provide a variant for NULL 241 encryption [RFC4279]. If confidentiality protection is required, 242 a carefully chosen set of algorithms may have a positive impact on 243 the code size. Re-use of crypto-libraries (within TLS but also 244 among the entire protocol stack) will also help to reduce the 245 overall code size. 247 o What functionality is available in hardware? For example, certain 248 hardware platforms offer support for a random number generator as 249 well as cryptographic algorithms (e.g., AES). These functions can 250 be re-used and allow to reduce the amount of required code. Using 251 hardware support not only reduces the computation time but can 252 also save energy due to the optimized implementation. 254 o What credentials for client and server authentication are 255 required: passwords, pre-shared secrets, certificates, raw public 256 keys (or a mixture of them)? Is mutual authentication required? 257 Is X509 certificate handling necessary? If not, then the ASN.1 258 library as well as the certificate parsing and processing can be 259 omitted. If pre-shared secrets are used then the big integer 260 implementation can be omitted. 262 o What TLS version and what TLS features, such as session 263 resumption, can or have to be used? In the case of DTLS, generic 264 fragmentation and reordering requires large buffers to reassemble 265 the messages, which might be too heavy for some devices. 267 o Is it possible to design only the client-side TLS stack, or 268 necessary to provide the server-side implementation as well? 269 Handshake messages sent are different sizes for the client and 270 server which creates energy consumption differences (due to the 271 fact that more power is spent during transmission than while 272 receiving data in wireless devices). 274 o Which side will be more powerful? Resource-constrained sensor 275 nodes running CoAPS might be server only, while nodes running 276 HTTPS are most like clients only that post their information to a 277 normal Web server. The constrained side will most likely only 278 implement a single ciphersuite. Flexibility is given to a more 279 powerful counterpart that supports many different ciphersuite for 280 various connected devices. 282 o Is it possible to hardwire credentials into the code rather than 283 loading them from storage? If so, then no file handling or 284 parsing of the credentials is needed and the credentials are 285 already available in a form that they can be used within the TLS 286 implementation. 288 4. Performance Numbers 290 In this section we summarize performance measurements available from 291 certain implementation experiences. This section is not supposed to 292 be exhaustive as we do not have all measurements available. The 293 performances are grouped according to extensions (TLS-PSK, raw-public 294 key and certificate based) and further grouped by performance 295 measures (memory, code size, communication overhead, etc.). Where 296 possible we extract the different building blocks found in TLS and 297 present their performance measures individually. 299 4.1. Pre-Shared Key (PSK) based DTLS implementation 301 This section provides performance numbers for a prototype 302 implementation of DTLS-PSK described in [I-D.keoh-lwig-dtls-iot] and 303 evaluates the memory and communication overheads. 305 4.1.1. Prototype Environment 307 The prototype is written in C and runs as an application on Contiki 308 OS 2.5 [Dunkels-Contiki], an event-driven open source operating 309 system for constrained devices. They were tested in the Cooja 310 simulator and then ported to run on Redbee Econotag hardware, which 311 features a 32-bit CPU, 128 KB of ROM, 96 KB of RAM, and an IEEE 312 802.15.4 enabled radio with an AES hardware coprocessor. The 313 prototype comprises all necessary functionality to adapt to the roles 314 as a domain manager or a joining device. 316 The prototype is based on the "TinyDTLS" [Bergmann-Tinydtls] library 317 and includes most of the extensions and the adaptation as follows: 319 1. The cookie mechanism was disabled in order to fit messages to the 320 available packet sizes and hence reducing the total number of 321 messages when performing the DTLS handshake. 323 2. Separate delivery was used instead of flight grouping of messages 324 and redesigned the retransmission mechanism accordingly. 326 3. The "TinyDTLS" AES-CCM module was modified to use the AES 327 hardware coprocessor. 329 The following subsections further analyze the memory and 330 communication overhead of the solution. 332 4.1.2. Code size and Memory Consumption 334 Table 1 presents the codesize and memory consumption of the prototype 335 differentiating (i) the state machine for the handshake, (ii) the 336 cryptographic primitives, and (iii) the DTLS record layer mechanism. 338 The use of DTLS appears to incur large memory footprint both in ROM 339 and RAM for two reasons. First, DTLS handshake defines many message 340 types and this adds more complexity to its corresponding state 341 machine. The logic for message re-ordering and retransmission also 342 contributes to the complexity of the DTLS state machine. Second, 343 DTLS uses SHA2-based crypto suites which is not available from the 344 hardware crypto co-processor. 346 +----------------------+-----------------+ 347 | | DTLS | 348 | +--------+--------+ 349 | | ROM | RAM | 350 +----------------------+--------+--------+ 351 | State Machine | 8.15 | 1.9 | 352 | Cryptography | 3.3 | 1.5 | 353 | DTLS Record Layer | 3.7 | 0.5 | 354 +----------------------+--------+--------+ 355 | TOTAL | 15.15 | 3.9 | 356 +----------------------+--------+--------+ 357 Table 1: Memory Requirements in KB 359 4.1.3. Communication Overhead 361 The communication overhead is evaluated in this section. In 362 particular, the message overhead and the number of exchanged bytes 363 under ideal condition without any packet loss is examined. 365 Table 2 summarizes the required number of round trips, number of 366 messages and the total exchanged bytes for the DTLS-based handshake 367 carried out in ideal conditions, i.e., in a network without packet 368 losses. DTLS handshake is considered complex as it involves the 369 exchange of 12 messages to complete the handshake. Further, DTLS 370 runs on top the transport layer, i.e., UDP, and hence this directly 371 increases the overhead due to lower layer per-packet protocol 372 headers. 374 +-------------------------------+--------+ 375 | | DTLS | 376 +-------------------------------+--------+ 377 | No. of Message | 8 | 378 | No. of round trips | 2 | 379 +-------------------------------+--------+ 380 | 802.15.4 headers | 112B | 381 | 6LowPAN headers | 320B | 382 | UDP headers | 64B | 383 +-------------------------------+--------+ 384 | TOTAL | 496B | 385 +-------------------------------+--------+ 386 Table 2: Communication overhead for Network 387 Access and Multicast Key Management 389 4.1.4. Message Delay, Success Rate and Bandwidth 391 The previous section provided an evaluation of the protocol in an 392 ideal condition, thus establishing the the baseline protocol 393 overhead. The prototype was further examined and simulated the 394 protocol behavior by tuning the packet loss ratio. In particular, 395 the impact of packet loss on message delay, success rate and number 396 of messages exchanged in the handshake were examined. 398 Figure 4 shows the percentage of successful handshakes as a function 399 of timeouts and packet loss ratios. As expected, a higher packet 400 loss ratio and smaller timeout (15s timeout) result in a failure 401 probability of completing the DTLS handshake. When the packet loss 402 ratio reaches 0.5, practically no DTLS handshake would be successful. 404 100 |+ 405 P | + 406 E 80 | ++ 407 R | ++ 408 C 60 | + 409 E | + 410 N 40 | + 411 T | ++ 412 A 20 | + 413 G | +++++ 414 E 0 +------------------++++++++-- 415 0 0.1 0.2 0.3 0.4 0.5 417 packet loss ratio (15s timeout) 419 Figure 1: Average % of successful handshakes 421 Delays in network access and communication are intolerable since they 422 lead to higher resource consumption. As the solution relies on PSK, 423 the handshake protocol only incurs a short delay of a few 424 milliseconds when there is no packet loss. However, as the packet 425 loss ratio increases, the delay in completing the handshake becomes 426 significant because loss packets must be retransmitted. Our 427 implementation shows that with a packet loss ratio of 0.5, the the 428 times to perform network access and multicast key management could 429 take up to 24s. 431 Finally, another important criterion is the number of messages 432 exchanged in the presence of packet loss. A successful handshake 433 could incur up to 35 or more messages to be transmitted when the 434 packet loss ratio reaches 0.5. This is mainly because the DTLS 435 retransmission is complex and often requires re-sending multiple 436 messages even when only a single message has been lost. 438 4.2. Certificate based and Raw-public key based TLS implementation 440 4.2.1. Prototype Environment 442 The following code was compiled under Ubuntu Linux using the -Os 443 compiler flag setting for a 64-bit AMD machine using a modified 444 version of the axTLS embedded SSL implementation. 446 4.2.2. Code size 448 For the cryptographic support functions these are the binary sizes: 450 +----------------------------+---------------+ 451 | Cryptographic functions | Code size | 452 +----------------------------+---------------+ 453 | MD5 | 4,856 bytes | 454 | SHA1 | 2,432 bytes | 455 | HMAC | 2,928 bytes | 456 | RSA | 3,984 bytes | 457 | Big Integer Implementation | 8,328 bytes | 458 | AES | 7,096 bytes | 459 | RC4 | 1,496 bytes | 460 | Random Number Generator | 4,840 bytes | 461 +----------------------------+---------------+ 462 Table 3: Code-size for cryptographic functions 464 The TLS library with certificate support consists of the following 465 parts: 467 x509 related code: 2,776 bytes The x509 related code provides 468 functions to parse certificates, to copy them into the program 469 internal data structures and to perform certificate related 470 processing functions, like certificate verification. 472 ASN1 Parser: 5,512 bytes The ASN1 library contains the necessary code 473 to parse ASN1 data. 475 Generic TLS Library: 15,928 bytes This library is separated from the 476 TLS client specific code to offer those functions that are common 477 with the client and the server-side implementation. This includes 478 code for the master secret generation, certificate validation and 479 identity verification, computing the finished message, ciphersuite 480 related functions, encrypting and decrypting data, sending and 481 receiving TLS messages (e.g., finish message, alert messages, 482 certificate message, session resumption). 484 TLS Client Library: 4,584 bytes The TLS client-specific code includes 485 functions that are only executed by the client based on the supported 486 ciphersuites, such as establishing the connection with the TLS 487 server, sending the ClientHello handshake message, parsing the 488 ServerHello handshake message, processing the ServerHelloDone 489 message, sending the ClientKeyExchange message, processing the 490 CertificateRequest message. 492 OS Wrapper Functions: 2,776 bytes These functions aim to make 493 development easier (e.g., for failure handling with memory allocation 494 and various header definitions) but are not absolutely necessary. 496 OpenSSL Wrapper Functions: 931 bytes The OpenSSL API calls are 497 familiar to many programmers and therefore these wrapper functions 498 are provided to simplify application development. This library is 499 also not absolutely necessary. 501 Certificate Processing Functions: 4,456 bytes These functions provide 502 the ability to load certificates from files (or to use a default key 503 as a static data structure embedded during compile time), to parse 504 them, and populate corresponding data structures. 506 4.2.3. Raw Public Key Implementation 508 Of course, the use of raw public keys does not only impact the code 509 size but also the size of the exchanged messages. When using raw 510 public keys (instead of certificates) the "certificate" size was 511 reduced from 475 bytes to 163 bytes (using an RSA-based public key). 512 Note that the SubjectPublicKeyInfo block does not only contain the 513 raw keys, namely the public exponent and the modulus, but also a 514 small ASN.1 header preamble. 516 For the raw public key implementation the following components where 517 needed (in addition to a subset of the cryptographic support 518 functions): 520 Minimal ASN1 Parser: 3,232 bytes The necessary support from the ASN1 521 library now only contains functions for parsing of the ASN1 522 components of the SubjectPublicKeyInfo block. 524 Generic TLS Library: 16,288 bytes This size of this library was 525 slightly enlarged since additional functionality for loading keys 526 into the bigint data structure was added. On the other hand, code 527 was removed that relates to certificate processing and functions to 528 retrieve certificate related data (e.g., to fetch the X509 529 distinguished name or the subject alternative name). 531 TLS Client Library: 4,528 bytes The TLS client-specific code now 532 contains additional code for the raw public key support, for example 533 in the ClientHello message. Most functions were left unmodified. 535 5. Summary and Conclusions 537 TLS/DTLS can be tailored to fit the needs of a specific deployment 538 environment. This customization property allows it to be tailored to 539 many use cases including smart objects. The communication model and 540 the security goals will, however, ultimately decide the resulting 541 code size; this is not only true for TLS but for every security 542 solution.More flexibility and more features will ultimately translate 543 to a bigger footprint. 545 There are, however, cases where the security goals ask for a security 546 solution other than TLS. With the wide range of embedded 547 applications it is impractical to design for a single security 548 architecture or even a single communication architecture. 550 6. Security Considerations 552 This document discusses various design aspects for reducing the 553 footprint of (D)TLS implementations. As such, it is entirely about 554 security. 556 7. IANA Considerations 558 This document does not contain actions for IANA. 560 8. Acknowledgements 562 The authors would like to thank the participants of the Smart Object 563 Security workshop, March 2012. The authors greatly acknowledge the 564 prototyping and implementation efforts by Pedro Moreno-Sanchez, 565 Francisco Vidal-Meca and Oscar Garcia-Morchon. 567 9. References 569 9.1. Normative References 571 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 572 RFC 2246, January 1999. 574 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 575 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 577 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 578 Security", RFC 4347, April 2006. 580 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 581 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 583 [SHA] NIST, , "Secure Hash Standard", FIPS 180-2, August 2002. 585 9.2. Informative References 587 [Bergmann-Tinydtls] 588 Bergmann, O., "TinyDTLS - A Basic DTLS Server: 589 http://tinydtls.sourceforge.net", 2012. 591 [Dunkels-Contiki] 592 Dunkels, A., Gronvall, B., and T. Voigt, "Contiki - A 593 Lightweight and Flexible Operating System for Tiny 594 Networked Sensors", IEEE In Proceedings of the 29th Annual 595 IEEE International Conference on Local Computer Networks, 596 2004. 598 [I-D.gilger-smart-object-security-workshop] 599 Gilger, J. and H. Tschofenig, "Report from the 'Smart 600 Object Security Workshop', March 23, 2012, Paris, France", 601 draft-gilger-smart-object-security-workshop-02 (work in 602 progress), October 2013. 604 [I-D.ietf-tls-oob-pubkey] 605 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 606 T. Kivinen, "Using Raw Public Keys in Transport Layer 607 Security (TLS) and Datagram Transport Layer Security 608 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), 609 January 2014. 611 [I-D.keoh-lwig-dtls-iot] 612 Keoh, S., Kumar, S., and O. Garcia-Morchon, "Securing the 613 IP-based Internet of Things with DTLS", draft-keoh-lwig- 614 dtls-iot-02 (work in progress), August 2013. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 620 Ciphersuites for Transport Layer Security (TLS)", RFC 621 3268, June 2002. 623 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 624 June 2005. 626 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 627 for Transport Layer Security (TLS)", RFC 4279, December 628 2005. 630 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 631 Ciphersuites with NULL Encryption for Transport Layer 632 Security (TLS)", RFC 4785, January 2007. 634 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 635 for Establishing a Secure Real-time Transport Protocol 636 (SRTP) Security Context Using Datagram Transport Layer 637 Security (DTLS)", RFC 5763, May 2010. 639 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 640 Extension Definitions", RFC 6066, January 2011. 642 [TLS-IANA] 643 IANA, , "Transport Layer Security (TLS) 644 Parameters:http://www.iana.org/assignments/tls-parameters/ 645 tls-parameters.xml", October 2012. 647 Authors' Addresses 648 Sandeep S. Kumar 649 Philips Research 650 High Tech Campus 34 651 Eindhoven 5656 AE 652 NL 654 Email: sandeep.kumar@philips.com 656 Sye Loong Keoh 657 University of Glasgow Singapore 658 Republic PolyTechnic, 9 Woodlands Ave 9 659 Singapore 838964 660 SG 662 Email: SyeLoong.Keoh@glasgow.ac.uk 664 Hannes Tschofenig 665 ARM Ltd. 666 110 Fulbourn Rd 667 Cambridge CB1 9NJ 668 Great Britain 670 Email: Hannes.Tschofenig@gmx.net