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