idnits 2.17.1 draft-tschofenig-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 (October 22, 2012) is 4197 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) ** 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) -- 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-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 J. Gilger 5 Expires: April 25, 2013 RWTH Aachen University 6 October 22, 2012 8 A Minimal (Datagram) Transport Layer Security Implementation 9 draft-tschofenig-lwig-tls-minimal-01.txt 11 Abstract 13 Transport Layer Security (TLS) is a widely used security protocol 14 that offers communication security services at the transport layer. 15 The initial design of TLS was focused on the protection of 16 applications running on top of the Transmission Control Protocol 17 (TCP), and was a good match for securing the Hypertext Transfer 18 Protocol (HTTP). Subsequent standardization efforts lead to the 19 publication of Datagram Transport Layer Security (DTLS), which added 20 the User Datagram Protocol (UDP), and the Datagram Congestion Control 21 Protocol (DCCP). The Stream Control Transmission Protocol (SCTP), as 22 a more recent connection-oriented transport protocol, also benefits 23 from TLS support. 25 TLS can be customized in a variety of ways and every feature has a 26 certain cost. To offer input for implementers and system architects 27 this document illustrates the impact each selected TLS features has 28 on the overall code size. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 25, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Communication Relationships . . . . . . . . . . . . . . . . . 5 65 3. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 The IETF published three versions of Transport Layer Security: TLS 78 Version 1.0 [RFC2246], TLS Version 1.1 [RFC4346], and TLS Version 1.2 79 [RFC5246]. Section 1.1 of [RFC4346] explains the differences between 80 Version 1.0 and Version 1.1; those are small security improvements, 81 including the usage of an explicit initialization vector to protect 82 against cipher-block-chaining attacks, which all have little impact 83 for the size of the code. Section 1.2 of [RFC5246] describes the 84 differences between Version 1.1 and Version 1.2. TLS 1.2 introduces 85 a couple of major changes with impact to size of an implementation. 86 In particular, prior TLS versions hardcoded the MD5/SHA-1 combination 87 in the pseudorandom function (PRF). As a consequence, any TLS 88 Version 1.0 and Version 1.1 implementation had to have MD5 and SHA-1 89 code even if the remaining cryptographic primitives used other 90 algorithms. With TLS Version 1.2 the two had been replaced with 91 cipher-suite-specified PRFs. In addition, the TLS extensions 92 definition [RFC6066] and various AES ciphersuites [RFC3268] got 93 merged into the TLS Version 1.2 specification. 95 All three TLS specifications list a mandatory-to-implement 96 ciphersuite: for TLS Version 1.0 this was 97 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, for TLS Version 1.1 it was 98 TLS_RSA_WITH_3DES_EDE_CBC_SHA, and for TLS Version 1.2 it is 99 TLS_RSA_WITH_AES_128_CBC_SHA. There is, however, an important 100 qualification to these compliance statements, namely that they are 101 only valid in the absence of an application profile standard 102 specifying otherwise. 104 All TLS versions offer a separation between authentication and key 105 exchange and bulk data protection. The former is more costly 106 performance- and message-wise. The details of the authentication and 107 key exchange, using the TLS Handshake, vary with the chosen 108 ciphersuite. With new ciphersuites the TLS feature-set can easily be 109 enhanced, in case the already large collection of ciphersuites, see 110 [TLS-IANA], does not match the requirements. 112 Once the TLS Handshake has been successfully completed the necessary 113 keying material and parameters are setup for usage with the TLS 114 Record Layer, which is responsible for bulk data protection. The TLS 115 Record Layer could be compared with the IPsec AH and IPsec ESP while 116 the Handshake protocol can be compared with the Internet Key Exchange 117 Version 2 (IKEv2). The provided security of the TLS Record Layer 118 depends also, but not only, on the chosen ciphersuite algorithms; 119 NULL encryption ciphersuites, like those specified in RFC 4785 120 [RFC4785], offer only integrity- without confidentiality-protection. 121 Example ciphersuites for the TLS Record Layer are RC4 with SHA-1, 122 AES-128 with SHA-1, AES-256 with SHA-1, RC4 with SHA-1, RC4 with MD5 123 It is worth mentioning that TLS may also be used without the TLS 124 Record Layer. This has, for example, been exercised with the work on 125 the framework for establishing a Secure Real-time Transport Protocol 126 (SRTP) security context using the Datagram Transport Layer Security 127 (DTLS [RFC4347]) protocol (DTLS-SRTP [RFC5763]). 129 2. Communication Relationships 131 A security solution is strongly influenced by the communication 132 relationships [RFC4101], which will have an impact on the code size. 133 Having a good understanding of these relationships will be essential. 135 Consider the following scenario where a smart meter transmits its 136 energy readings to other parties. The public utility has to ensure 137 that the meter readings it obtained can be attributed to a specific 138 meter in a household. It is simply not acceptable for public utility 139 to have any meter readings in transit or by a rogue endpoint 140 (particularly if the attack leads to a disadvantage, for example 141 financial loss, for the utility). Users in a household may want to 142 ensure that only certain parties are able to read their meter; 143 privacy concerns come to mind. 145 In this example, a sensor may only ever need to talk to servers of a 146 specific utility or even only to a single pre-configured server. 147 Clearly, some information has to be pre-provisioned into the device 148 to ensure the desired behavior to talk only to selected servers. The 149 meter may come pre-configured with the domain name and certificate 150 belonging to the utility. The device may, however, also be 151 configured to accept one or multiple server certificates. It may 152 even be pre-provisioned with the server's raw public key, or a shared 153 secret instead of relying on certificates. 155 Lowering the flexibility decreases the implementation overhead. TLS- 156 PSK [RFC4279], if shared secrets are used, or raw public keys used 157 with TLS [I-D.ietf-tls-oob-pubkey] require fewer lines of code than 158 employing X.509 certificate, as it will be explained later in this 159 document. A decision for constraining the client-side TLS 160 implementation, for example by offering only a single ciphersuite, 161 has to be made in awareness of what functionality will be available 162 on the TLS server-side. In certain communication environments it may 163 be easy to influence both communication partners while in other cases 164 the existing deployment needs to be taken into consideration. 166 To illustrate another example, consider an Internet radio, which 167 allows a user to connect to available radio stations. A device like 168 this will be more demanding than an IP-enabled scale that only 169 connects to the single Web server offered by the device manufacturer. 170 A threat assessment may even lead to the conclusion that TLS support 171 is not necessary at all. 173 Consider the following extension to our earlier scenario where the 174 meter is attached to a home WLAN network and the interworking with 175 WLAN security mechanisms need to be taken care of. On top of the 176 link layer authentication, a transport layer or application layer 177 security mechanism needs to be implemented. Quite likely the 178 security mechanisms will be different due to the different credential 179 requirements. While there is a possibility for re-use of 180 cryptographic libraries (such as the SHA-1, MD5, or HMAC) the overall 181 code footprint will very likely be larger. 183 3. Design Decisions 185 To evaluate the required TLS functionality a couple of high level 186 design decisions have to be made: 188 o What type of protection for the data traffic is required? Is 189 confidentiality protection in addition to integrity protection 190 required? Many TLS ciphersuites also provide a variant for NULL 191 encryption. If confidentiality protection is required, a 192 carefully chosen set of algorithms may have a positive impact on 193 the code size. For example, the RC4 stream cipher code size is 194 1,496 bytes compared to 7,096 bytes for AES usage. Re-use of 195 crypto-libraries (within TLS but also among the entire protocol 196 stack) will also help to reduce the overall code size. 198 o What functionality is available in hardware? For example, certain 199 hardware platforms offer support for a random number generator as 200 well as cryptographic algorithms (e.g., AES). These functions can 201 be re-used and allow to reduce the amount of required code. 203 o What credentials for client and server authentication are 204 required: passwords, pre-shared secrets, certificates, raw public 205 keys (or a mixture of them)? Is certificate handling necessary? 206 If not, then the ASN.1 library as well as the certificate parsing 207 and processing can be omitted. If pre-shared secrets are used 208 then the big integer implementation can be omitted. 210 o What TLS version and what TLS features, such as session 211 resumption, can or have to be used? 213 o Is necessary to design only the client-side TLS stack, or to 214 provide the server-side implementation as well? 216 o Is it possible to hardwire credentials into the code rather than 217 loading them from storage? If so, then no file handling or 218 parsing of the credentials is needed and the credentials are 219 already available in form that they can be used within the TLS 220 implementation. 222 4. Conclusion 224 The IAB published a document, RFC 5218 [RFC5218], on the success 225 criteria for protocols. A "wildly successful" protocol far exceeds 226 its original goals, in terms of purpose (being used in scenarios far 227 beyond the initial design), in terms of scale (being deployed on a 228 scale much greater than originally envisaged), or both. TLS is an 229 example of such a wildly successful protocol. It can be tailored to 230 fit the needs of a specific deployment environment. This 231 customization property offers the basis for a relatively small code 232 footprint. The communication model and the security goals will, 233 however, ultimately decide about the resulting code size; this is not 234 only true for TLS but for every security solution. 236 More flexibility and more features will translate to a bigger 237 footprint. Generic complaints about the large size of TLS stacks are 238 not useful and should be accompanied by a description of the assumed 239 functionality. To support the author's opinion this position paper 240 provides information about the amount of required code for various 241 functions and considers most recent work from the IETF TLS working 242 group for the support of raw public keys. 244 The author is convinced that TLS is a suitable security protocol 245 (with the standardized extensions) for usage in many smart object 246 deployments. Only minor extensions, as currently being developed in 247 the IETF TLS working group, are needed to support an even larger set 248 of use cases. There are, however, cases where the security goals ask 249 for a security solution other than TLS. With the wide range of 250 embedded applications it is impractical to design for a single 251 security architecture or even a single communication architecture. 253 5. Security Considerations 255 This document discusses various design aspects for reducing the 256 footprint of TLS implementations. As such, it is entirely about 257 security. 259 6. IANA Considerations 261 This document does not contain actions for IANA. 263 7. Acknowledgements 265 The author would like to thank the participants of the Smart Object 266 Security workshop, March 2012. 268 8. References 270 8.1. Normative References 272 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 273 RFC 2246, January 1999. 275 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 276 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 278 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 279 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 281 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 282 Security", RFC 4347, April 2006. 284 8.2. Informative References 286 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 287 Extension Definitions", RFC 6066, January 2011. 289 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 290 Ciphersuites for Transport Layer Security (TLS)", 291 RFC 3268, June 2002. 293 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 294 for Establishing a Secure Real-time Transport Protocol 295 (SRTP) Security Context Using Datagram Transport Layer 296 Security (DTLS)", RFC 5763, May 2010. 298 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 299 Ciphersuites with NULL Encryption for Transport Layer 300 Security (TLS)", RFC 4785, January 2007. 302 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 303 for Transport Layer Security (TLS)", RFC 4279, 304 December 2005. 306 [I-D.ietf-tls-oob-pubkey] 307 Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 308 Tschofenig, "Out-of-Band Public Key Validation for 309 Transport Layer Security", draft-ietf-tls-oob-pubkey-04 310 (work in progress), July 2012. 312 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 313 Protocol?", RFC 5218, July 2008. 315 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 316 June 2005. 318 [TLS-IANA] 319 IANA, "Transport Layer Security (TLS) Parameters: http:// 320 www.iana.org/assignments/tls-parameters/ 321 tls-parameters.xml", Oct 2012. 323 Authors' Addresses 325 Hannes Tschofenig 326 Nokia Siemens Networks 327 Linnoitustie 6 328 Espoo, 02600 329 Finland 331 Phone: +358 (50) 4871445 332 Email: Hannes.Tschofenig@gmx.net 333 URI: http://www.tschofenig.priv.at 335 Johannes Gilger 336 RWTH Aachen University 337 Mies-van-der-Rohe-Str. 15 338 Aachen, 52074 339 Germany 341 Phone: +49 (0)241 80 20 781 342 Email: Gilger@ITSec.RWTH-Aachen.de