idnits 2.17.1 draft-ietf-tls-encrypt-then-mac-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 (May 2, 2014) is 3646 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 5246 (ref. '2') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (ref. '3') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 6347 (ref. '4') (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group P. Gutmann 2 Internet-Draft University of Auckland 3 Intended status: Standards Track May 2, 2014 4 Expires: November 3, 2014 6 Encrypt-then-MAC for TLS and DTLS 7 draft-ietf-tls-encrypt-then-mac-01.txt 9 Abstract 11 This document describes a means of negotiating the use of the 12 encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing 13 MAC-then-encrypt one, which has been the subject of a number of 14 security vulnerabilities over a period of many years. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 3, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 52 2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . 2 53 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . 3 55 3.1. Rehandshake Issues . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 7.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 [2] and [4] use a MAC-then-encrypt construction that was regarded as 67 secure at the time the original SSL protocol was specified in the 68 mid-1990s, but that is no longer regarded as secure [5] [6]. This 69 construction, as used in TLS and later DTLS, has been the subject of 70 numerous security vulnerabilities and attacks stretching over a 71 period of many years. This document specifies a means of switching 72 to the more secure encrypt-then-MAC construction as part of the TLS/ 73 DTLS handshake, replacing the current MAC-then-encrypt construction. 75 1.1. Conventions Used in This Document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [1]. 81 2. Negotiating Encrypt-then-MAC 83 The use of encrypt-then-MAC is negotiated via TLS/DTLS extensions as 84 defined in [2]. On connecting, the client includes the 85 encrypt_then_MAC extension in its client_hello if it wishes to use 86 encrypt-then-MAC rather than the default MAC-then-encrypt. If the 87 server is capable of meeting this requirement, it responds with an 88 encrypt_then_MAC in its server_hello. The "extension_type" value for 89 this extension is [TBD - expected value is 22, 0x16] and the 90 "extension_data" field of this extension SHALL be empty. 92 2.1. Rationale 94 The use of TLS/DTLS extensions to negotiate an overall switch is 95 preferable to defining new ciphersuites because the latter would 96 result in a Cartesian explosion of suites, potentially requiring 97 duplicating every single existing suite with a new one that uses 98 encrypt-then-MAC. In contrast the approach presented here requires 99 just a single new extension type with a corresponding minimal-length 100 extension sent by client and server. 102 Another possibility for introducing encrypt-then-MAC would be to make 103 it part of TLS 1.3, however this would require the implementation and 104 deployment of all of TLS 1.2 just to support a trivial code change in 105 the order of encryption and MAC'ing. In contrast deploying encrypt- 106 then-MAC via the TLS/DTLS extension mechanism required changing less 107 than a dozen lines of code in one implementation (not including the 108 handling for the new extension type, which was a further 50 or so 109 lines of code). 111 The use of extensions precludes use with SSL 3.0, but then it's 112 likely that anything still using this nearly two decades-old protocol 113 will be vulnerable to any number of other attacks anyway, so there 114 seems little point in bending over backwards to accomodate SSL 3.0. 116 3. Applying Encrypt-then-MAC 118 Once the use of encrypt-then-MAC has been negotiated, processing of 119 TLS/DTLS packets switches from the standard: 121 encrypt( data || MAC || pad ) 123 to the new: 125 encrypt( data || pad ) || MAC 127 with the MAC covering the entire packet up to the start of the MAC 128 value. In [2] notation the MAC calculation is: 130 MAC(MAC_write_key, seq_num + 131 TLSCipherText.type + 132 TLSCipherText.version + 133 TLSCipherText.length + 134 ENC(content + padding + padding_length)); 136 for TLS 1.0 without the explicit IV and: 138 MAC(MAC_write_key, seq_num + 139 TLSCipherText.type + 140 TLSCipherText.version + 141 TLSCipherText.length + 142 IV + 143 ENC(content + padding + padding_length)); 145 for TLS 1.1 and greater with explicit IV (for DTLS the sequence 146 number is replaced by the combined epoch and sequence number as per 147 [4]). The final MAC value is then appended to the encrypted data and 148 padding. This calculation is identical to the existing one with the 149 exception that the MAC calculation is run over the payload ciphertext 150 (the TLSCipherText PDU) rather than the plaintext (the TLSCompressed 151 PDU). 153 The overall TLS packet [2] is then: 155 struct { 156 ContentType type; 157 ProtocolVersion version; 158 uint16 length; 159 GenericBlockCipher fragment; 160 opaque MAC; 161 } TLSCiphertext; 163 The equivalent DTLS packet [4] is then: 165 struct { 166 ContentType type; 167 ProtocolVersion version; 168 uint16 epoch; 169 uint48 sequence_number; 170 uint16 length; 171 GenericBlockCipher fragment; 172 opaque MAC; 173 } TLSCiphertext; 175 This is identical to the existing TLS/DTLS layout with the only 176 difference being that the MAC value is moved outside the encrypted 177 data. 179 Note from the GenericBlockCipher annotation that this only applies to 180 standard block ciphers that have distinct encrypt and MAC operations. 181 It does not apply to GenericStreamCiphers, or to GenericAEADCiphers 182 that already include integrity protection with the cipher. If a 183 server receives an encrypt-then-MAC request extension from a client 184 and then selects a stream or AEAD cipher suite, it MUST NOT send an 185 encrypt-then-MAC response extension back to the client. 187 Decryption reverses this processing. The MAC SHALL be evaluated 188 before any further processing such as decryption is performed, and if 189 the MAC verification fails then processing SHALL terminate 190 immediately. For TLS, a fatal bad_record_mac MUST be generated [2]. 191 For DTLS, the record MUST be discarded and a fatal bad_record_mac MAY 192 be generated [2]. This immediate response to a bad MAC eliminates 193 any timing channels that may be available through the use of 194 manipulated packet data. 196 Some implementations may prefer to use a truncated MAC rather than a 197 full-length one. In this case they MAY negotiate the use of a 198 truncated MAC through the TLS truncated_hmac extension as defined in 199 [3]. 201 [(To be removed by RFC Editor) 203 Implementation note: There is a test server available for 204 interop testing at https://eid.vx4.net:443/. This uses the 205 "extension_type" value 0x15 for the encrypt_then_MAC extension, 206 which was the first unassigned TLS extension value at the time 207 the original specification was written. It is expected that 208 the final "extension_type" value will be 22, 0x16. The server 209 has been tested successfully with several different 210 implementations]. 212 3.1. Rehandshake Issues 214 The status of encrypt-then-MAC vs. MAC-then-encrypt can potentially 215 change during a rehandshake. Implementations SHOULD retain the 216 current session state for the renegotiated session (in other words if 217 the mechanism for the current session is X then the renegotiated 218 session should also use X). While implementations SHOULD NOT change 219 the state during a rehandshake, if they wish to be more flexible then 220 the following rules apply: 222 +------------------+---------------------+--------------------------+ 223 | Current Session | Renegotiated | Action to take | 224 | | Session | | 225 +------------------+---------------------+--------------------------+ 226 | MAC-then-encrypt | MAC-then-encrypt | No change | 227 | | | | 228 | MAC-then-encrypt | Encrypt-then-MAC | Upgrade to Encrypt-then- | 229 | | | MAC | 230 | | | | 231 | Encrypt-then-MAC | MAC-then-encrypt | Error | 232 | | | | 233 | Encrypt-then-MAC | Encrypt-then-MAC | No change | 234 +------------------+---------------------+--------------------------+ 236 Table 1: Encrypt-then-MAC with Renegotiation 238 As the above table points out, implementations MUST NOT renegotiate a 239 downgrade from Encrypt-then-MAC to MAC-then-encrypt. Note that a 240 client or server that doesn't wish to implement the mechanism-change- 241 during-rehandshake ability can (as a client) not request a mechanism 242 change and (as a server) deny the mechanism change. 244 If an upgrade from MAC-then-encrypt to Encrypt-then-MAC is negotiated 245 as per the second line in the table above then the change will take 246 place in the first message that follows the Change Cipher Spec (CCS). 247 In other words all messages up to and including the CCS will use MAC- 248 then-encrypt, and then the message that follows will continue with 249 Encrypt-then-MAC. 251 4. Security Considerations 253 This document defines an improved security mechanism encrypt-then-MAC 254 to replace the current MAC-then-encrypt one. This is regarded as 255 more secure than the current mechanism [5] [6], and should mitigate 256 or eliminate a number of attacks on the current mechanism, provided 257 that the instructions on MAC processing given in Section 3 are 258 applied. 260 An active attacker who can emulate a client or server with extension 261 intolerance may cause some implementations to fall back to older 262 protocol versions that don't support extensions, which will in turn 263 force a fallback to non-Encrypt-then-MAC behaviour. A 264 straightforward solution to this problem is to avoid fallback to 265 older, less secure protocol versions. If fallback behaviour is 266 unavoidable then mechanisms to address this issue, which affects all 267 capabilities that are negotiated via TLS extensions, are being 268 developed by the TLS working group [7]. Anyone concerned about this 269 type of attack should consult the TLS working group documents for 270 guidance on appropriate defence mechanisms. 272 5. IANA Considerations 274 This document defines a new extension for TLS/DTLS. IANA[should 275 allocate extension number 22 (0x16) for this extension. 277 6. Acknowledgements 279 The author would like to thank Martin Rex, Dan Shumow, and the 280 members of the TLS mailing list for their feedback on this document. 282 7. References 284 7.1. Normative References 286 [1] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [2] Dierks, T. and E. Rescorla, "The Transport Layer Security 290 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 292 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 293 and T. Wright, "Transport Layer Security (TLS) 294 Extensions", RFC 4366, April 2006. 296 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 297 Security Version 1.2", RFC 6347, January 2012. 299 7.2. Informative References 301 [5] Bellare, M. and C. Namprempre, "Authenticated Encryption: 302 Relations among notions and analysis of the generic 303 composition paradigm", Springer-Verlag LNCS 1976, December 304 2000. 306 [6] Krawczyk, H., "The Order of Encryption and Authentication 307 for Protecting Communications (or: How Secure Is SSL?)", 308 Springer-Verlag LNCS 2139, August 2001. 310 [7] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 311 Suite Value (SCSV) for Preventing Protocol Downgrade 312 Attacks", RFC XXXX, November 2013. 314 Author's Address 316 Peter Gutmann 317 University of Auckland 318 Department of Computer Science 319 University of Auckland 320 New Zealand 322 Email: pgut001@cs.auckland.ac.nz