idnits 2.17.1 draft-tschofenig-lwig-tls-minimal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 15, 2012) is 4205 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 18, 2013 RWTH Aachen University 6 October 15, 2012 8 A Minimal (Datagram) Transport Layer Security Implementation 9 draft-tschofenig-lwig-tls-minimal-00.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 implications of selected TLS features 28 for the 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 18, 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 SHA1 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 SHA1, 122 AES128 with SHA1, AES256 with SHA1, RC4 with SHA1, 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 impacted 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 electricity company will want 137 to make sure that the obtained meter readings can be attributed to a 138 specific meter in a household. Most electricity companies will find 139 it unacceptable to have meter readings modified in transit or by a 140 rogue endpoint (particularly if the attack leads to a disadvantage, 141 for example financial loss, for the electricity provider). Users in 142 a household may want to ensure that only certain parties get to see 143 the meter readings; privacy concerns come to mind. 145 In this example a sensor may need to only ever talk to servers of a 146 specific electricity company or even only to a single pre-configured 147 server. Clearly, some information has to be pre-provisioned into the 148 device to ensure the desired behavior to talk only to selected 149 servers. The meter may be configured with the domain name used by 150 the electricity company and with the root certificate that is used by 151 the electricity company to sign certificates for their servers. The 152 device may, however, also be configured to accept one or multiple 153 server certificates. It may even be pre-provisioned with the 154 server's raw public key, or a shared secret instead of relying on 155 certificates. 157 Lowering the flexibility decreases the implementation overhead. TLS- 158 PSK [RFC4279], in case of shared secret usage, or raw public keys 159 used with TLS [I-D.ietf-tls-oob-pubkey] require fewer lines of code 160 than x509 certificate usage, as it will be explained later in this 161 document. A decision for constraining the client-side TLS 162 implementation, for example by offering only a single ciphersuite, 163 has to be made in awareness of what functionality will be available 164 on the TLS server-side. In certain communication environments it may 165 be easy to influence both communication partners while in other cases 166 the existing deployment needs to be taken into consideration. 168 To illustrate another example, consider an Internet radio, which 169 allows a user to connect to available radio stations. A device like 170 this will be demanding than an IP-enabled scale that connects only to 171 the Web server offered by the manufacturer of that device. A threat 172 assessment may even lead to the conclusion that TLS support is not 173 necessary at all. 175 Consider the following extension to our earlier scenario where the 176 meter is attached to a home WLAN network and the interworking with 177 WLAN security mechanisms need to be taken care of. On top of the 178 link layer authentication a transport layer or application layer 179 security mechanism needs to be implemented. Quite likely the 180 security mechanisms will be different due to the different credential 181 requirements. While there is a possibility for re-use of 182 cryptographic libraries (such as the SHA-1, MD5, or HMAC) the overall 183 code footprint will very likely be larger. 185 3. Design Decisions 187 To evaluate the required TLS functionality a couple of high level 188 design decisions have to be made: 190 o What type of protection for the data traffic is required? Is 191 confidentiality protection in addition to integrity protection 192 required? Many TLS ciphersuites also provide a variant for NULL 193 encryption. If confidentiality protection is demanded, a 194 carefully chosen set of algorithms may have a positive impact on 195 the code size. For example, the RC4 stream cipher code size is 196 1,496 bytes compared to 7,096 bytes for AES usage. Re-use of 197 crypto-libraries (within TLS but also among the entire protocol 198 stack) will also help to reduce the overall code size. 200 o What functionality is available in hardware? For example, certain 201 hardware platforms offer support for a random number generator as 202 well as cryptographic algorithms (e.g., AES). These functions can 203 be re-used and allow to reduce the amount of required code. 205 o What credentials for client and server authentication are 206 required: passwords, pre-shared secrets, certificates, raw public 207 keys (or a mixture of them)? Is certificate handling necessary? 208 If not, then the ASN.1 library as well as the certificate parsing 209 and processing can be omitted. If pre-shared secrets are used 210 then the big integer implementation can be omitted. 212 o What TLS version and what TLS features, such as session 213 resumption, can or have to be used? 215 o Is a client-side stack of TLS needed only or is also the server- 216 side implementation necessary as well? 218 o Is it possible to hardwire credentials into the code rather than 219 loading them from storage? If so, then no file handling or 220 parsing of the credentials is needed and the credentials are 221 already available in form that they can be used within the TLS 222 implementation. 224 4. Conclusion 226 The IAB published a document, RFC 5218 [RFC5218], on the success 227 criteria for protocols. A "wildly successful" protocol far exceeds 228 its original goals, in terms of purpose (being used in scenarios far 229 beyond the initial design), in terms of scale (being deployed on a 230 scale much greater than originally envisaged), or both. TLS is an 231 example of such a wildly successful protocol. It can be tailored to 232 fit the needs of a specific deployment environment. This 233 customization property offers the basis for a relatively small code 234 footprint. The communication model and the security goals will, 235 however, ultimately decide about the resulting code size; this is not 236 only true for TLS but for every security solution. 238 More flexibility and more features will translate to a bigger 239 footprint. Generic complaints about the large size of TLS stacks are 240 not useful and should be accompanied by a description of the assumed 241 functionality. To support the author's opinion this position paper 242 provides information about the amount of required code for various 243 functions and considers most recent work from the IETF TLS working 244 group for the support of raw public keys. 246 The author is convinced that TLS is a suitable security protocol 247 (with the standardized extensions) for usage in many smart object 248 deployments. Only minor extensions, as currently being developed in 249 the IETF TLS working group, are needed to support an even large set 250 of use cases. There are, however, cases where the security goals ask 251 for a security solution other than TLS. With the wide range of 252 embedded applications it is impractical to design for a single 253 security architecture or even a single communication architecture. 255 5. Security Considerations 257 This document discusses various design aspects for reducing the 258 footprint of TLS implementations. As such, it is entirely about 259 security. 261 6. IANA Considerations 263 This document does not contain actions for IANA. 265 7. Acknowledgements 267 The author would like to thank the participants of the Smart Object 268 Security workshop, March 2012. 270 8. References 272 8.1. Normative References 274 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 275 RFC 2246, January 1999. 277 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 278 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 280 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 281 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 283 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 284 Security", RFC 4347, April 2006. 286 8.2. Informative References 288 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 289 Extension Definitions", RFC 6066, January 2011. 291 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 292 Ciphersuites for Transport Layer Security (TLS)", 293 RFC 3268, June 2002. 295 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 296 for Establishing a Secure Real-time Transport Protocol 297 (SRTP) Security Context Using Datagram Transport Layer 298 Security (DTLS)", RFC 5763, May 2010. 300 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 301 Ciphersuites with NULL Encryption for Transport Layer 302 Security (TLS)", RFC 4785, January 2007. 304 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 305 for Transport Layer Security (TLS)", RFC 4279, 306 December 2005. 308 [I-D.ietf-tls-oob-pubkey] 309 Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 310 Tschofenig, "Out-of-Band Public Key Validation for 311 Transport Layer Security", draft-ietf-tls-oob-pubkey-04 312 (work in progress), July 2012. 314 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 315 Protocol?", RFC 5218, July 2008. 317 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 318 June 2005. 320 [TLS-IANA] 321 IANA, "Transport Layer Security (TLS) Parameters: http:// 322 www.iana.org/assignments/tls-parameters/ 323 tls-parameters.xml", Oct 2012. 325 Authors' Addresses 327 Hannes Tschofenig 328 Nokia Siemens Networks 329 Linnoitustie 6 330 Espoo, 02600 331 Finland 333 Phone: +358 (50) 4871445 334 Email: Hannes.Tschofenig@gmx.net 335 URI: http://www.tschofenig.priv.at 337 Johannes Gilger 338 RWTH Aachen University 339 Mies-van-der-Rohe-Str. 15 340 Aachen, 52072 341 Germany 343 Phone: +49 (0)241 80 20 781 344 Email: Gilger@ITSec.RWTH-Aachen.de