Encrypt-then-MAC for TLS and DTLSUniversity of AucklandDepartment of Computer ScienceUniversity of AucklandAucklandNew Zealandpgut001@cs.auckland.ac.nz
Security Area
TLS Working GroupInternet-Draft
This document describes a means of negotiating the use of the encrypt-then-MAC
security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which
has been the subject of a number of security vulnerabilities over a period of
many years.
and use 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
. 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.
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 .
The use of encrypt-then-MAC is negotiated via TLS/DTLS extensions as defined
in . 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.
The use of TLS/DTLS 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.
Another possibility for introducing encrypt-then-MAC would be to make it part
of TLS 1.3, however this would require the implementation and deployment of
all of TLS 1.2 just to support a trivial code change in the order of
encryption and MAC'ing. In contrast deploying encrypt-then-MAC via the
TLS/DTLS extension mechanism required changing less than a dozen lines of code
in one implementation (not including the handling for the new extension type,
which was a further 50 or so lines of code).
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.
Once the use of encrypt-then-MAC has been negotiated, processing of TLS/DTLS
packets switches from the standard:
to the new:
with the MAC covering the entire packet up to the start of the MAC value. In
notation the MAC calculation is:
for TLS 1.0 without the explicit IV and:
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 notation the overall packet is then:
This is identical to the existing TLS layout with the single exception being
that the MAC value is moved outside the encrypted data. The change for DTLS
follows similarly (the only difference being that instead of the 64 bit
sequence number, in its place DTLS contains the two 32 bit fields 'epoch' and
'sequence_number' between the version and length).
Note from the GenericStreamCipher/GenericBlockCipher annotation that this only
applies to standard stream and block ciphers that have distinct encrypt and
MAC operations. It does not apply to GenericAEADCiphers that already include
integrity protection with the cipher. If a server receives an encrypt-then-
MAC request extension from a client and then selects an AEAD cipher suite, it
MUST NOT send a encrypt-then-MAC response extension back to the client.
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.
The status of encrypt-then-MAC vs. MAC-then-encrypt can potentially change
during a rehandshake. Implementations SHOULD retain the current session state
for the renegotiated session (in other words if the mechanism for the current
session is X then the renegotiated session should also use X). If
implementations wish to be more flexible then the following rules apply.
Current SessionRenegotiated SessionAction to takeMAC-then-encryptMAC-then-encryptNo changeMAC-then-encryptEncrypt-then-MACUpgrade to MAC-then-encryptEncrypt-then-MACMAC-then-encryptErrorEncrypt-then-MACEncrypt-then-MACNo change
Note that a client or server that doesn't wish to implement the mechanism-
change-during-rehandshake ability can (as a client) not request a mechanism
change and (as a server) deny the mechanism change.
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 , and should mitigate or eliminate a number of
attacks on the current mechanism, provided that the instructions on MAC
processing given in are applied.
This document defines a new extension for TLS/DTLS.
The author would like to thank the members of the TLS mailing list for their
feedback on this document and Dan Shumow for the suggestions around DTLS.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University
General
keywordThe Transport Layer Security (TLS) Protocol Version 1.2IndependentRTFM, Inc.Transport Layer Security (TLS) ExtensionsSafeNet Technologies BVRSA SecurityIndependent ConsultantTransactionwareVodafoneDatagram Transport Layer Security Version 1.2RTFM, Inc.Stanford UniversityAuthenticated Encryption: Relations among notions and analysis of the generic composition paradigmUCSDThammasat UniversityThe Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)IBM Research