This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. This document updates RFCs 4492, 5705,
and 6066 and it obsoletes RFCs 5077, 5246, and 6961. This document
also specifies new requirements for TLS 1.2 implementations.

The Transport Layer Security (TLS) Protocol Version 1.3

The Internet Protocol.

TLS was designed as a transparent channel abstraction to allow developers with no cryptographic expertise to protect their application against attackers that may control some clients, some servers, and may have the capability to tamper with network connections. However, the security guarantees of TLS fall short of those of a secure channel, leading to a variety of attacks. We show how some widespread false beliefs about these guarantees can be exploited to attack popular applications and defeat several standard authentication methods that rely too naively on TLS. We present new client impersonation attacks against TLS renegotiations, wireless networks, challenge-response protocols, and channel-bound cookies. Our attacks exploit combinations of RSA and Diffie-Hellman key exchange, session resumption, and renegotiation to bypass many recent countermeasures. We also demonstrate new ways to exploit known weaknesses of HTTP over TLS. We investigate the root causes for these attacks and propose new countermeasures. At the protocol level, we design and implement two new TLS extensions that strengthen the authentication guarantees of the handshake. At the application level, we develop an exemplary HTTPS client library that implements several mitigations, on top of a previously verified TLS implementation, and verify that their composition provides strong, simple application security.

/pdf/triple-handshakes-and-cookie-cutters-breaking-and-fixing-1frumnlyss.pdf

Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS

SSL and TLS renegotiation are vulnerable to an attack in which the
attacker forms a TLS connection with the target server, injects
content of his choice, and then splices in a new TLS connection from a
client. The server treats the client's initial TLS handshake as a
renegotiation and thus believes that the initial data transmitted by
the attacker is from the same entity as the subsequent client data.
This draft defines a TLS extension to cryptographically tie
renegotiations to the TLS connections they are being performed over,
thus preventing this attack.

/pdf/transport-layer-security-tls-renegotiation-indication-4idjr8ynbt.pdf

Transport Layer Security (TLS) Renegotiation Indication Extension

In response to high-profile attacks that exploit hash function collisions, software vendors have started to phase out the use of MD5 and SHA-1 in third-party digital signature applications such as X.509 certificates. However, weak hash constructions continue to be used in various cryptographic constructions within mainstream protocols such as TLS, IKE, and SSH, because practitioners argue that their use in these protocols relies only on second preimage resistance, and hence is unaffected by collisions. This paper systematically investigates and debunks this argument. We identify a new class of transcript collision attacks on key exchange protocols that rely on efficient collision-finding algorithms on the underlying hash constructions. We implement and demonstrate concrete credential-forwarding attacks on TLS 1.2 client authentication, TLS 1.3 server authentication, and TLS channel bindings. We describe almost-practical impersonation and downgrade attacks in TLS 1.1, IKEv2 and SSH-2. As far as we know, these are the first collision-based attacks on the cryptographic constructions used in these popular protocols. Our practical attacks on TLS were responsibly disclosed (under the name SLOTH) and have resulted in security updates to several TLS libraries. Our analysis demonstrates the urgent need for disabling all uses of weak hash functions in mainstream protocols, and our recommendations have been incorporated in the upcoming Token Binding and TLS 1.3 protocols.

/pdf/transcript-collision-attacks-breaking-authentication-in-tls-4ct5hkaahw.pdf

Transcript Collision Attacks: Breaking Authentication in TLS, IKE and SSH.

The concept of channel binding allows applications to establish that
the two end-points of a secure channel at one network layer are the
same as at a higher layer by binding authentication at the higher
layer to the channel at the lower layer. This allows applications to
delegate session protection to lower layers, which has various
performance benefits. This document discusses and formalizes the
concept of channel binding to secure channels.

On the Use of Channel Bindings to Secure Channels

This document defines three channel binding types for Transport Layer
Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
telnet, in accordance with RFC 5056 (On Channel Binding).

Channel Bindings for TLS

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use. This specification describes a
family of Simple Authentication and Security Layer (SASL; RFC 4422)
authentication mechanisms called the Salted Challenge Response
Authentication Mechanism (SCRAM), which addresses the security
concerns and meets the deployability requirements. When used in
combination with TLS or an equivalent security layer, a mechanism from
this family could improve the status quo for application protocol
authentication and provide a suitable choice for a mandatory-to-
implement mechanism for future application protocol standards.
[STANDARDS-TRACK]

Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding. Only GSS-API mechanisms that support channel binding
are supported. See for more
information.

Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family

This document clarifies and generalizes the Generic Security Services
Application Programming Interface (GSS-API) "channel bindings"
facility, and imposes requirements on future GSS-API mechanisms and
programming language bindings of the GSS-API.

/pdf/clarifications-and-extensions-to-the-generic-security-18la6hv65l.pdf

Nicolas Williams

Papers

On the Use of Channel Bindings to Secure Channels

Channel Bindings for TLS

Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms

Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family

Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings