Subject: Re: [TLS] TLS1.3

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Feb 2013 10:49:36 +0000

So here's the first cut, if there's anything that needs clarifying/changing
let me know before I upload it.

Peter.

-- Snip --

TLS Working Group                                             P. Gutmann
Internet-Draft                                    University of Auckland
Intended status: Standards Track                        February 7, 2013
Expires: August 11, 2013

                        Encrypt-then-MAC for TLS
               draft-gutmann-tls-encrypt-then-mac-00.txt

Abstract

   This document describes a means of negotiating the use of the
   encrypt-then-MAC security mechanism in place of TLS' existing MAC-
   then-encrypt one, which has been the subject of a number of security
   vulnerabilities over a period of many years.

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 August 11, 2013.

Copyright Notice

   Copyright (c) 2013 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                  Expires August 11, 2013                [Page 1]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions Used in This Document . . . . . . . . . . . . . 3
   2.  Negotiating Encrypt-then-MAC  . . . . . . . . . . . . . . . . . 4
   3.  Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Gutmann                  Expires August 11, 2013                [Page 2]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

1.  Introduction

   [TLS] uses a MAC-then-encrypt construction that was regarded as
   secure at the time the original SSL protocol was specified in the
   mid-1990s, but that is no longer regarded as secure
   [EncryptThenAuth].  This construction, as used in TLS, 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 handshake, replacing the current MAC-then-encrypt
   construction.

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

Gutmann                  Expires August 11, 2013                [Page 3]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

2.  Negotiating Encrypt-then-MAC

   The use of encrypt-then-MAC is negotiated via TLS extensions as
   defined in [TLS].  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 is [TBD] and the "extension_data" field of this
   extension SHALL be empty.

Gutmann                  Expires August 11, 2013                [Page 4]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

3.  Applying Encrypt-then-MAC

   Once the use of encrypt-then-MAC has been negotiated, processing of
   TLS packets switches from the standard:

    encrypt( data || MAC || pad )

   to the new:

    encrypt( data || pad ) || MAC

   with the MAC covering the entire packet up to the start of the MAC
   value.  In other words the MAC calculation is run over the packet
   header and metadata in the usual manner as specified in [TLS], and
   then over the encrypted data and padding.  The final MAC value is
   then appended to the encrypted data and padding.

   Decryption reverses this processing.  The MAC SHALL be evaluated
   before any further processing such as decryption is performed, and if
   the MAC verification fails then processing SHALL terminate
   immediately.  This eliminates any timing channels that may be
   available through the use of manipulated packet data.

Gutmann                  Expires August 11, 2013                [Page 5]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

4.  Security Considerations

   This document defines an improved security mechanism encrypt-then-MAC
   to replace the current MAC-then-encrypt one.  This is regarded as
   more secure than the current mechanism [EncryptThenAuth], and should
   mitigate or eliminate a number of attacks on the current mechanism,
   provided that the instructions on MAC processing given in Section 3
   are applied.

Gutmann                  Expires August 11, 2013                [Page 6]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

5.  IANA Considerations

   This document defines a new extension for TLS.

Gutmann                  Expires August 11, 2013                [Page 7]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [TLS-Ext]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

6.2.  Informative References

   [EncryptThenAuth]
              Krawczyk, H., "The Order of Encryption and Authentication
              for Protecting Communications (or: How Secure Is SSL?)",
              Springer-Verlag LNCS 2139, August 2001.

Gutmann                  Expires August 11, 2013                [Page 8]
^L
Internet-Draft          Encrypt-then-MAC-for-TLS           February 2013

Author's Address

   Peter Gutmann
   University of Auckland
   Department of Computer Science
   New Zealand

   Email: [email-masked]

Gutmann                  Expires August 11, 2013                [Page 9]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Feb 2013 11:47:23 +0000

Hi Peter

It would help to explain why this is better than just defining some new encrypt-then-MAC ciphersuites. Cartesian explosion is a good argument. Are there others?

Yoav

On Feb 8, 2013, at 12:49 PM, Peter Gutmann <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Email secured by Check Point

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 09:30:45 -0600

> It would help to explain why this is better than just defining some new encrypt-then-MAC ciphersuites. Cartesian explosion is a good argument. Are there others?

I think that argument is sufficient.  And maybe it's time to start
thinking about a general solution to the cipher suite cartesian
product of algorithms problem -- perhaps along the same lines as
Peter's I-D.

FWIW, I support Peter's approach here.

Nico
--