Re: [TLS] TLS1.3

[Yoav Nir <[e-mail]>]

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 <[e-mail]> wrote:

> 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: [e-mail]
> 
> Gutmann                  Expires August 11, 2013                [Page 9]
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Email secured by Check Point