Network Working Group N. Mavrogiannopoulos Internet-Draft Red Hat Updates: 5246,6347 (if approved) A. Pironti Intended status: Standards Track INRIA Paris-Rocquencourt Expires: May 21, 2014 November 17, 2013 A new TLS record padding mechanism draft-mavrogiannopoulos-new-tls-padding-01 Abstract This memo proposes a new padding mechanism the TLS and DTLS record protocols. It defines a TLS extension to allow arbitrary amount of padding in any ciphersuite. The new padding mechanism eliminates any known padding oracle attacks on the CBC ciphersuites and allows novel length hiding techniques. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 1] Internet-Draft A new TLS record padding mechanism November 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. TLS Extension: Extended Record Padding . . . . . . . . . . . 3 3.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 3 3.2. Record Payload . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The ciphersuites of the TLS protocol that utilize CBC block ciphers, [RFC5246][RFC6347] require the plaintext to be padded to a multiple of the cipher's block size prior to encryption. However, this padding, as implemented in TLS, has the following issues. 1. The plaintext is padded after it is authenticated, allowing for padding oracle attacks [CBCTIME][DTLS-ATTACK][LH-PADDING]. 2. It is limited to 255 bytes. 3. No other than the CBC ciphersuites can take advantage of padding to hide the length of the records. To overcome these limitations, the TLS extension proposed in this document enables a new padding mechanism for for both block and stream ciphers. The proposed extension eliminates padding oracles (both in errors and timing) that have been plaguing standard TLS block ciphers, without modifying critical aspects of the protocol such as the order of encryption and authentication. 2. Terminology Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 2] Internet-Draft A new TLS record padding mechanism November 2013 This document uses the same notation and terminology used in the TLS and DTLS protocol specifications [RFC5246][RFC6347]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. TLS Extension: Extended Record Padding The TLS extended record padding is a variant of the TLS record protocol where every record can be padded up to 2^14 bytes, regardless of the cipher being used. 3.1. Extension Negotiation In order to indicate the support of the new record padding, clients MUST include an extension of type "extended_record_padding" to the extended client hello message. The "extended_record_padding" TLS extension is assigned the value of TDB-BY-IANA from the TLS ExtensionType registry. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The hello extension mechanism is described in [RFC5246]. This extension carries no payload and indicates support for the extended record padding. The "extension_data" field of this extension are of zero length in both the client and the server. The negotiated record padding applies for the duration of the session, including session resumption. A client wishing to resume a session where the extended record padding was negotiated SHOULD include the "extended_record_padding" extension in the client hello. 3.2. Record Payload The translation of the TLSCompressed structure into TLSCiphertext remains the same as in [RFC5246]. When the cipher is BulkCipherAlgorithm.null, the 'fragment' structure of TLSCiphertext also remains unchanged. That is, for the TLS_NULL_WITH_NULL_NULL ciphersuite and for MAC-only ciphersuites this extension has no effect. For all other ciphersuites, the 'fragment' structure of TLSCiphertext is modified as follows. stream-ciphered struct { opaque pad<0..2^14>; opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; } GenericStreamCipher; Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 3] Internet-Draft A new TLS record padding mechanism November 2013 struct { opaque IV[SecurityParameters.record_iv_length]; block-ciphered ciphered struct { opaque pad<0..2^14>; opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; }; } GenericBlockCipher; struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque pad<0..2^14>; opaque content[TLSCompressed.length]; }; } GenericAEADCipher; The padding can be filled with arbitrary data, and it is authenticated as part of the MAC. For block ciphers, the length of the pad MUST be such that the total length (i.e., the pad, the content and the MAC) are a multiple of the block size. Note: In typical applications that take no steps to hide the length of the record and are not using block ciphers, the size of the pad will be zero. For the various ciphers the data are authenticated as follows. Standard Stream Ciphers: MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + length + TLSCiphertext.fragment.GenericStreamCipher.pad + TLSCompressed.fragment); Block Ciphers: MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + length + TLSCiphertext.fragment.GenericBlockCipher.pad + TLSCompressed.fragment); Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 4] Internet-Draft A new TLS record padding mechanism November 2013 AEAD Ciphers: additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + length; AEADEncrypted = AEAD-Encrypt(write_key, nonce, pad + plaintext, additional_data); length For all the above cases, a uint16 containing the sum of the padding length and the content length. Implementation note: With block and stream ciphers, in order to avoid padding oracles, decryption, MAC verification and payload decoding MUST be executed in the following order. 1. Decrypt TLSCiphertext.fragment. 2. Verify the MAC. 3. Split plaintext from pad. 4. Security Considerations Since the padding is always included in the MAC computation, attacks that utilize the CBC-padding timing channel (e.g., [DTLS-ATTACK]) are not applicable. In a way, the extended record padding can be seen as a special way of encoding application data before encryption (where application data given by the user are prefixed by some padding). Hence, previous security results on standard TLS block and stream ciphers still apply to the extended record padding. 5. IANA Considerations This document defines a new TLS extension, "extended_record_padding", assigned a value of TBD-BY-IANA (the value 48015 is suggested) from the TLS ExtensionType registry defined in [RFC5246]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. 6. Normative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 5] Internet-Draft A new TLS record padding mechanism November 2013 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DTLS-ATTACK] Nadhem, N. and K. Paterson, "Plaintext-recovery attacks against datagram TLS.", Network and Distributed System Security Symposium , 2012. [LH-PADDING] Pironti, A., Strub, P., and K. Bhargavan, "Identifying Website Users by TLS Traffic Analysis: New Attacks and Effective Countermeasures.", INRIA Research Report 8067 , 2012. [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, "Password Interception in a SSL/TLS Channel", Advances in Cryptology -- CRYPTO , 2003. Appendix A. Acknowledgements The authors wish to thank Kenny Paterson for his suggestions on improving this document. Authors' Addresses Nikos Mavrogiannopoulos Red Hat Purkynova 99/75a Brno 612 00 Czech Republic Email: nmav@redhat.com Alfredo Pironti INRIA Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France Email: alfredo.pironti@inria.fr Mavrogiannopoulos & PirontExpires May 21, 2014 [Page 6]