TLS Working Group P. Gutmann
Internet-Draft University of Auckland
Intended status: Standards Track February 8, 2013
Expires: August 12, 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 12, 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 12, 2013 [Page 1]
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
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Gutmann Expires August 12, 2013 [Page 2]
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 12, 2013 [Page 3]
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.
2.1. Rationale
The use of TLS extensions to negotiate an overall switch is
preferable to defining new ciphersuites because the latter would
result in a Cartesian explosion of suites, potentially requiring
duplicating every single existing suite with a new one that uses
encrypt-then-MAC. In contrast the approach presented here requires
just a single new extension type with a corresponding minimal-length
extension sent by client and server.
The use of extensions precludes use with SSL 3.0, but then it's
likely that anything still using this nearly two decades-old protocol
will be vulnerable to any number of other attacks anyway, so there
seems little point in bending over backwards to accomodate SSL 3.0.
Gutmann Expires August 12, 2013 [Page 4]
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 [TLS] notation the MAC calculation is:
MAC(MAC_write_key, seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
ENC(content + padding + padding_length));
for TLS 1.0 without the explicit IV and:
MAC(MAC_write_key, seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
IV +
ENC(content + padding + padding_length));
for TLS 1.1 and greater with explicit IV. The final MAC value is
then appended to the encrypted data and padding. Note that this
calculation is identical to the existing one with the exception that
the MAC calculation is run over the payload ciphertext rather than
the plaintext.
In [TLS] notation the overall packet is then:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
GenericStream/BlockCipher fragment;
opaque MAC;
} TLSCiphertext;
Note that this is identical to the existing TLS layout with the
single exception being that the MAC value is moved outside the
encrypted data.
Gutmann Expires August 12, 2013 [Page 5]
Internet-Draft Encrypt-then-MAC-for-TLS February 2013
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 12, 2013 [Page 6]
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 12, 2013 [Page 7]
Internet-Draft Encrypt-then-MAC-for-TLS February 2013
5. IANA Considerations
This document defines a new extension for TLS.
Gutmann Expires August 12, 2013 [Page 8]
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 12, 2013 [Page 9]
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 12, 2013 [Page 10]