idnits 2.17.1 draft-mavrogiannopoulos-new-tls-padding-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6347, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2013) is 3810 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 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'DTLS-ATTACK' -- Possible downref: Non-RFC (?) normative reference: ref. 'LH-PADDING' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBCTIME' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft Red Hat 4 Updates: 5246,6347 (if approved) A. Pironti 5 Intended status: Standards Track INRIA Paris-Rocquencourt 6 Expires: May 21, 2014 November 17, 2013 8 A new TLS record padding mechanism 9 draft-mavrogiannopoulos-new-tls-padding-01 11 Abstract 13 This memo proposes a new padding mechanism the TLS and DTLS record 14 protocols. It defines a TLS extension to allow arbitrary amount of 15 padding in any ciphersuite. The new padding mechanism eliminates any 16 known padding oracle attacks on the CBC ciphersuites and allows novel 17 length hiding techniques. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 21, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. TLS Extension: Extended Record Padding . . . . . . . . . . . 3 56 3.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 3 57 3.2. Record Payload . . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The ciphersuites of the TLS protocol that utilize CBC block ciphers, 67 [RFC5246][RFC6347] require the plaintext to be padded to a multiple 68 of the cipher's block size prior to encryption. However, this 69 padding, as implemented in TLS, has the following issues. 71 1. The plaintext is padded after it is authenticated, allowing for 72 padding oracle attacks [CBCTIME][DTLS-ATTACK][LH-PADDING]. 74 2. It is limited to 255 bytes. 76 3. No other than the CBC ciphersuites can take advantage of padding 77 to hide the length of the records. 79 To overcome these limitations, the TLS extension proposed in this 80 document enables a new padding mechanism for for both block and 81 stream ciphers. The proposed extension eliminates padding oracles 82 (both in errors and timing) that have been plaguing standard TLS 83 block ciphers, without modifying critical aspects of the protocol 84 such as the order of encryption and authentication. 86 2. Terminology 87 This document uses the same notation and terminology used in the TLS 88 and DTLS protocol specifications [RFC5246][RFC6347]. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. TLS Extension: Extended Record Padding 96 The TLS extended record padding is a variant of the TLS record 97 protocol where every record can be padded up to 2^14 bytes, 98 regardless of the cipher being used. 100 3.1. Extension Negotiation 102 In order to indicate the support of the new record padding, clients 103 MUST include an extension of type "extended_record_padding" to the 104 extended client hello message. The "extended_record_padding" TLS 105 extension is assigned the value of TDB-BY-IANA from the TLS 106 ExtensionType registry. This value is used as the extension number 107 for the extensions in both the client hello message and the server 108 hello message. The hello extension mechanism is described in 109 [RFC5246]. 111 This extension carries no payload and indicates support for the 112 extended record padding. The "extension_data" field of this 113 extension are of zero length in both the client and the server. 115 The negotiated record padding applies for the duration of the 116 session, including session resumption. A client wishing to resume a 117 session where the extended record padding was negotiated SHOULD 118 include the "extended_record_padding" extension in the client hello. 120 3.2. Record Payload 122 The translation of the TLSCompressed structure into TLSCiphertext 123 remains the same as in [RFC5246]. When the cipher is 124 BulkCipherAlgorithm.null, the 'fragment' structure of TLSCiphertext 125 also remains unchanged. That is, for the TLS_NULL_WITH_NULL_NULL 126 ciphersuite and for MAC-only ciphersuites this extension has no 127 effect. For all other ciphersuites, the 'fragment' structure of 128 TLSCiphertext is modified as follows. 130 stream-ciphered struct { 131 opaque pad<0..2^14>; 132 opaque content[TLSCompressed.length]; 133 opaque MAC[SecurityParameters.mac_length]; 134 } GenericStreamCipher; 135 struct { 136 opaque IV[SecurityParameters.record_iv_length]; 137 block-ciphered ciphered struct { 138 opaque pad<0..2^14>; 139 opaque content[TLSCompressed.length]; 140 opaque MAC[CipherSpec.hash_size]; 141 }; 142 } GenericBlockCipher; 144 struct { 145 opaque nonce_explicit[SecurityParameters.record_iv_length]; 146 aead-ciphered struct { 147 opaque pad<0..2^14>; 148 opaque content[TLSCompressed.length]; 149 }; 150 } GenericAEADCipher; 152 The padding can be filled with arbitrary data, and it is 153 authenticated as part of the MAC. For block ciphers, the length of 154 the pad MUST be such that the total length (i.e., the pad, the 155 content and the MAC) are a multiple of the block size. 157 Note: In typical applications that take no steps to hide the length 158 of the record and are not using block ciphers, the size of the pad 159 will be zero. 161 For the various ciphers the data are authenticated as follows. 163 Standard Stream Ciphers: 165 MAC(MAC_write_key, seq_num + 166 TLSCompressed.type + 167 TLSCompressed.version + 168 length + 169 TLSCiphertext.fragment.GenericStreamCipher.pad + 170 TLSCompressed.fragment); 172 Block Ciphers: 174 MAC(MAC_write_key, seq_num + 175 TLSCompressed.type + 176 TLSCompressed.version + 177 length + 178 TLSCiphertext.fragment.GenericBlockCipher.pad + 179 TLSCompressed.fragment); 181 AEAD Ciphers: 183 additional_data = seq_num + TLSCompressed.type + 184 TLSCompressed.version + length; 186 AEADEncrypted = AEAD-Encrypt(write_key, nonce, 187 pad + plaintext, 188 additional_data); 190 length 191 For all the above cases, a uint16 containing the sum of the 192 padding length and the content length. 194 Implementation note: With block and stream ciphers, in order to avoid 195 padding oracles, decryption, MAC verification and payload decoding 196 MUST be executed in the following order. 198 1. Decrypt TLSCiphertext.fragment. 200 2. Verify the MAC. 202 3. Split plaintext from pad. 204 4. Security Considerations 206 Since the padding is always included in the MAC computation, attacks 207 that utilize the CBC-padding timing channel (e.g., [DTLS-ATTACK]) are 208 not applicable. 210 In a way, the extended record padding can be seen as a special way of 211 encoding application data before encryption (where application data 212 given by the user are prefixed by some padding). Hence, previous 213 security results on standard TLS block and stream ciphers still apply 214 to the extended record padding. 216 5. IANA Considerations 218 This document defines a new TLS extension, "extended_record_padding", 219 assigned a value of TBD-BY-IANA (the value 48015 is suggested) from 220 the TLS ExtensionType registry defined in [RFC5246]. This value is 221 used as the extension number for the extensions in both the client 222 hello message and the server hello message. 224 6. Normative References 226 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 227 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 229 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 230 Security Version 1.2", RFC 6347, January 2012. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [DTLS-ATTACK] 236 Nadhem, N. and K. Paterson, "Plaintext-recovery attacks 237 against datagram TLS.", Network and Distributed System 238 Security Symposium , 2012. 240 [LH-PADDING] 241 Pironti, A., Strub, P., and K. Bhargavan, "Identifying 242 Website Users by TLS Traffic Analysis: New Attacks and 243 Effective Countermeasures.", INRIA Research Report 8067 , 244 2012. 246 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, 247 "Password Interception in a SSL/TLS Channel", Advances in 248 Cryptology -- CRYPTO , 2003. 250 Appendix A. Acknowledgements 252 The authors wish to thank Kenny Paterson for his suggestions on 253 improving this document. 255 Authors' Addresses 257 Nikos Mavrogiannopoulos 258 Red Hat 259 Purkynova 99/75a 260 Brno 612 00 261 Czech Republic 263 Email: nmav@redhat.com 265 Alfredo Pironti 266 INRIA Paris-Rocquencourt 267 23, Avenue d'Italie 268 Paris 75214 CEDEX 13 269 France 271 Email: alfredo.pironti@inria.fr