uta | Y. Sheffer |
Internet-Draft | Porticor |
Intended status: Informational | R. Holz |
Expires: September 28, 2014 | TUM |
P. Saint-Andre | |
&yet | |
March 27, 2014 |
Summarizing Current Attacks on TLS and DTLS
draft-ietf-uta-tls-attacks-00
Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DTLS.
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 September 28, 2014.
Copyright (c) 2014 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.
Over the last few years there have been several major attacks on TLS [RFC5246], including attacks on its most commonly used ciphers and modes of operation. Details are given in Section 2, but suffice it to say that both AES-CBC and RC4, which together make up for most current usage, have been seriously attacked in the context of TLS.
This situation motivated the creation of the UTA working group, which is tasked with the creation of generic and protocol-specific recommendation for the use of TLS and DTLS.
“Attacks always get better; they never get worse” (ironically, this saying is attributed to the NSA). This list of attacks describes our knowledge as of this writing. It seems likely that new attacks will be invented in the future.
For a more detailed discussion of the attacks listed here, the interested reader is referred to [Attacks-iSec].
This section lists the attacks that motivated the current recommendations. This is not intended to be an extensive survey of TLS's security.
While there are widely deployed mitigations for some of the attacks listed below, we believe that their root causes necessitate a more systemic solution.
The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation of CBC (that is, the predictable initialization vector) to decrypt parts of a packet, and specifically shows how this can be used to decrypt HTTP cookies when run over TLS.
A consequence of the MAC-then-encrypt design in all current versions of TLS is the existence of padding oracle attacks [Padding-Oracle]. A recent incarnation of these attacks is the Lucky Thirteen attack [CBC-Attack], a timing side-channel attack that allows the attacker to decrypt arbitrary ciphertext.
The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) for many years. Attacks have also been known for a long time, e.g. [RC4-Attack-FMS]. But recent attacks ([RC4-Attack], [RC4-Attack-AlF]) have weakened this algorithm even more. See [I-D.popov-tls-prohibiting-rc4] for more details.
The CRIME attack [CRIME] allows an active attacker to decrypt cyphertext (specifically, cookies) when TLS is used with protocol-level compression.
The TIME attack [TIME] and the later BREACH attack [BREACH] both make similar use of HTTP-level compression to decrypt secret data passed in the HTTP response. We note that compression of the HTTP message body is much more prevalent than compression at the TLS level.
The former attack can be mitigated by disabling TLS compression, as recommended below. We are not aware of mitigations at the protocol level to the latter attack, and so application-level mitigations are needed (see [BREACH]). For example, implementations of HTTP that use CSRF tokens will need to randomize them even when the recommendations of [I-D.ietf-uta-tls-bcp] are adopted.
This document describes protocol attacks in an informational manner, and in itself does not have any security implications. Its companion documents certainly do.
This document requires no IANA actions.
We would like to thank Stephen Farrell, Simon Josefsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, and Rich Salz for their review of a previous version of this document.
The document was prepared using the lyx2rfc tool, created by Nico Williams.
[RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
Note to RFC Editor: please remove this section before publication.