idnits 2.17.1 draft-gutmann-tls-encrypt-then-mac-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 (February 8, 2013) is 4088 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: 'TBD' is mentioned on line 89, but not defined == Unused Reference: 'TLS-Ext' is defined on line 185, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (ref. 'TLS-Ext') (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: Standards Track February 8, 2013 5 Expires: August 12, 2013 7 Encrypt-then-MAC for TLS 8 draft-gutmann-tls-encrypt-then-mac-00.txt 10 Abstract 12 This document describes a means of negotiating the use of the 13 encrypt-then-MAC security mechanism in place of TLS' existing MAC- 14 then-encrypt one, which has been the subject of a number of security 15 vulnerabilities over a period of many years. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 12, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 53 2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . . 4 54 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 1. Introduction 65 [TLS] uses a MAC-then-encrypt construction that was regarded as 66 secure at the time the original SSL protocol was specified in the 67 mid-1990s, but that is no longer regarded as secure 68 [EncryptThenAuth]. This construction, as used in TLS, has been the 69 subject of numerous security vulnerabilities and attacks stretching 70 over a period of many years. This document specifies a means of 71 switching to the more secure encrypt-then-MAC construction as part of 72 the TLS handshake, replacing the current MAC-then-encrypt 73 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 [RFC2119]. 81 2. Negotiating Encrypt-then-MAC 83 The use of encrypt-then-MAC is negotiated via TLS extensions as 84 defined in [TLS]. 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] and the "extension_data" field of this 90 extension SHALL be empty. 92 2.1. Rationale 94 The use of TLS 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 The use of extensions precludes use with SSL 3.0, but then it's 103 likely that anything still using this nearly two decades-old protocol 104 will be vulnerable to any number of other attacks anyway, so there 105 seems little point in bending over backwards to accomodate SSL 3.0. 107 3. Applying Encrypt-then-MAC 109 Once the use of encrypt-then-MAC has been negotiated, processing of 110 TLS packets switches from the standard: 112 encrypt( data || MAC || pad ) 114 to the new: 116 encrypt( data || pad ) || MAC 118 with the MAC covering the entire packet up to the start of the MAC 119 value. In [TLS] notation the MAC calculation is: 121 MAC(MAC_write_key, seq_num + 122 TLSCompressed.type + 123 TLSCompressed.version + 124 TLSCompressed.length + 125 ENC(content + padding + padding_length)); 127 for TLS 1.0 without the explicit IV and: 129 MAC(MAC_write_key, seq_num + 130 TLSCompressed.type + 131 TLSCompressed.version + 132 TLSCompressed.length + 133 IV + 134 ENC(content + padding + padding_length)); 136 for TLS 1.1 and greater with explicit IV. The final MAC value is 137 then appended to the encrypted data and padding. Note that this 138 calculation is identical to the existing one with the exception that 139 the MAC calculation is run over the payload ciphertext rather than 140 the plaintext. 142 In [TLS] notation the overall packet is then: 144 struct { 145 ContentType type; 146 ProtocolVersion version; 147 uint16 length; 148 GenericStream/BlockCipher fragment; 149 opaque MAC; 150 } TLSCiphertext; 152 Note that this is identical to the existing TLS layout with the 153 single exception being that the MAC value is moved outside the 154 encrypted data. 156 Decryption reverses this processing. The MAC SHALL be evaluated 157 before any further processing such as decryption is performed, and if 158 the MAC verification fails then processing SHALL terminate 159 immediately. This eliminates any timing channels that may be 160 available through the use of manipulated packet data. 162 4. Security Considerations 164 This document defines an improved security mechanism encrypt-then-MAC 165 to replace the current MAC-then-encrypt one. This is regarded as 166 more secure than the current mechanism [EncryptThenAuth], and should 167 mitigate or eliminate a number of attacks on the current mechanism, 168 provided that the instructions on MAC processing given in Section 3 169 are applied. 171 5. IANA Considerations 173 This document defines a new extension for TLS. 175 6. References 177 6.1. Normative References 179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP 14, RFC 2119, March 1997. 182 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 183 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 185 [TLS-Ext] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 186 and T. Wright, "Transport Layer Security (TLS) 187 Extensions", RFC 4366, April 2006. 189 6.2. Informative References 191 [EncryptThenAuth] 192 Krawczyk, H., "The Order of Encryption and Authentication 193 for Protecting Communications (or: How Secure Is SSL?)", 194 Springer-Verlag LNCS 2139, August 2001. 196 Author's Address 198 Peter Gutmann 199 University of Auckland 200 Department of Computer Science 201 New Zealand 203 Email: pgut001@cs.auckland.ac.nz