Internet DRAFT - draft-mavrogiannopoulos-new-tls-padding

draft-mavrogiannopoulos-new-tls-padding







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]