Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
RFC 7366

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03

Internet Engineering Task Force (IETF)                        P. Gutmann
Request for Comments: 7366                        University of Auckland
Category: Standards Track                                 September 2014
ISSN: 2070-1721

        Encrypt-then-MAC for Transport Layer Security (TLS) and
                Datagram Transport Layer Security (DTLS)

Abstract

   This document describes a means of negotiating the use of the
   encrypt-then-MAC security mechanism in place of the existing MAC-
   then-encrypt mechanism in Transport Layer Security (TLS) and Datagram
   Transport Layer Security (DTLS).  The MAC-then-encrypt mechanism has
   been the subject of a number of security vulnerabilities over a
   period of many years.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7366.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Gutmann                      Standards Track                    [Page 1]
RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   2
   2.  Negotiating Encrypt-then-MAC  . . . . . . . . . . . . . . . .   2
     2.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . .   3
     3.1.  Rehandshake Issues  . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7

1.  Introduction

   TLS [2] and DTLS [4] use a MAC-then-encrypt construction that was
   regarded as secure at the time the original Secure Socket Layer (SSL)
   protocol was specified in the mid-1990s, but that is no longer
   regarded as secure [5] [6].  This construction, as used in TLS and
   later DTLS, has been the subject of numerous security vulnerabilities
   and attacks stretching over a period of many years.  This document
   specifies a means of switching to the more secure encrypt-then-MAC
   construction as part of the TLS/DTLS handshake, replacing the current
   MAC-then-encrypt construction.  (In this document, "MAC" refers to
   "Message Authentication Code".)

1.1.  Conventions Used in This Document

   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 [1].

2.  Negotiating Encrypt-then-MAC

   The use of encrypt-then-MAC is negotiated via TLS/DTLS extensions as
   defined in TLS [2].  On connecting, the client includes the
   encrypt_then_mac extension in its client_hello if it wishes to use
   encrypt-then-MAC rather than the default MAC-then-encrypt.  If the
   server is capable of meeting this requirement, it responds with an
   encrypt_then_mac in its server_hello.  The "extension_type" value for
   this extension SHALL be 22 (0x16), and the "extension_data" field of
   this extension SHALL be empty.  The client and server MUST NOT use
   encrypt-then-MAC unless both sides have successfully exchanged
   encrypt_then_mac extensions.

Gutmann                      Standards Track                    [Page 2]
RFC 7366            Encrypt-then-MAC for TLS and DTLS     September 2014

2.1.  Rationale

   The use of TLS/DTLS extensions to negotiate an overall switch is
   preferable to defining new ciphersuites because the latter would