Re: [TLS] TLS1.3
Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 08 February 2013 10:49 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91A821F8700 for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 02:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ys3Fn4U04k4 for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 02:49:39 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6F33C21F86C9 for <tls@ietf.org>; Fri, 8 Feb 2013 02:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320578; x=1391856578; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Q72+NO8V4ZqTOm02Gfe59IjBaIG9FiaKeppconIsFc0=; b=eIbr0tg0yAAq5ekGEVCDLgy0+C9xUso3ALTV36udEiDsWixBzffv42GM H+KuYhebVtHmrpth1/Cn66JKLGCFWTJAWtVJ+zt8S+WF0nRWSmeceumpp m24C2odOmhGQ1Dmeog3IAQweFdcRB2iwRw3PJbQXMInVIuWyN+gJhirY2 8=;
X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577793"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:49:37 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:49:37 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLS1.3
Thread-Index: Ac4F6fygZdSmOMX5RNWqCeZ5aQDRXQ==
Date: Fri, 08 Feb 2013 10:49:36 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEAFD@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2013 10:49:40 -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: pgut001@cs.auckland.ac.nz Gutmann Expires August 11, 2013 [Page 9]
- Re: [TLS] TLS1.3 Peter Gutmann
- [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 Eric Rescorla
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 Paterson, Kenny
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Eric Rescorla
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Dan Harkins
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Yoav Nir
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 David McGrew (mcgrew)
- Re: [TLS] TLS1.3 Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 Paterson, Kenny
- Re: [TLS] TLS1.3 Martin Rex
- Re: [TLS] TLS1.3 Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Martin Rex
- Re: [TLS] TLS1.3 Peter Gutmann
- Re: [TLS] TLS1.3 Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Paterson, Kenny
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Paterson, Kenny
- Re: [TLS] TLS1.3 Yoav Nir
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Lewis, Nick
- Re: [TLS] TLS1.3 Yoav Nir
- Re: [TLS] TLS1.3 Nikos Mavrogiannopoulos
- Re: [TLS] TLS1.3 Martin Rex
- Re: [TLS] TLS1.3 Nico Williams
- Re: [TLS] TLS1.3 Martin Rex
- Re: [TLS] TLS1.3 Russ Housley
- Re: [TLS] TLS1.3 Wan-Teh Chang
- Re: [TLS] TLS1.3 Scott Schmit
- Re: [TLS] TLS1.3 Martin Rex
- Re: [TLS] TLS1.3 Scott Schmit
- Re: [TLS] TLS1.3 Peter Gutmann