Found 3 records.

Status: Verified (1)

RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", February 2015

Errata ID: 4403
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sebastian Schinzel
Date Reported: 2015-06-28
Verifier Name: Stephen Farrell
Date Verified: 2015-06-29

Section 2.7 says:

While the Bleichenbacher attack has been mitigated in TLS 1.0,
the Klima attack, which relies on a version-check oracle, is only
mitigated by TLS 1.1.

It should say:

The Bleichenbacher attack has been first addressed in TLS 1.0. This
mitigation closed the error message-based attack, but opened a
potentially exploitable timing leak [*] which has been addressed in
TLS 1.2. The Klima attack, which relies on a version-check oracle,
is mitigated by TLS 1.1.

[*]: Revisiting SSL/TLS Implementations: New Bleichenbacher Side
Channels and Attacks. Meyer, Somorovsky, Weiss, Schwenk, Schinzel,
Tews.  23rd Usenix Security Symposium 2014.

Notes:

RFC 7457 states: "While the Bleichenbacher attack has been mitigated
in TLS 1.0, the Klima attack, which relies on a version-check oracle,
is only mitigated by TLS 1.1."

RFC 2246 (TLS 1.0) states: "The best way to avoid vulnerability
to this attack is to treat incorrectly formatted messages in a
manner indistinguishable from correctly formatted RSA blocks. Thus,
when it receives an incorrectly formatted RSA block, a server should
generate a random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the received
RSA block is correctly encoded or not."

This does not safely prevent Bleichenbacher style attacks. To rephrase
it: implementations should generate and proceed with a random PMS
if (implied "*and only if*") an incorrectly formatted message was
received. This opens a timing side channel that we successfully
exploited in several TLS implementations that comply with RFC 2246
(see [1], [2]).

This timing side channel was first addressed in TLS 1.2 (RFC 5246),
which gives the following timing-constant algorithm to prevent
Bleichenbacher's attack: "1. Generate a string R of 46 random bytes
2. Decrypt the message to recover the plaintext M 3. If the PKCS#1
padding is not correct, or the length of message
M is not exactly 48 bytes:
pre_master_secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and version
number check is explicitly disabled:
pre_master_secret = M
else:
pre_master_secret = ClientHello.client_version || M[2..47]"

Thus, it is not TLS 1.0 which safely prevents Bleichenbacher attacks,
but TLS 1.2.

Status: Reported (2)

RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", February 2015

Errata ID: 4592
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthäus Wander
Date Reported: 2016-01-10

Section 2.6 says:

The TIME attack can be mitigated by disabling TLS compression.  We
are not aware of mitigations at the TLS protocol level to the BREACH
attack, and so application-level mitigations are needed (see
[BREACH]).

It should say:

The CRIME attack can be mitigated by disabling TLS compression.  We
are not aware of mitigations at the TLS protocol level to the TIME and
BREACH attacks, and so application-level mitigations are needed (see
[BREACH]).

Notes:

As explained in the second paragraph in 2.6, the TIME attack makes use of HTTP-level response compression (in fact, it does not matter on which layer the compression occurs, but exploitation of HTTP-level response compression has been demonstrated). Hence, it cannot be mitigated by disabling TLS compression alone.

Instead, CRIME can be mitigated by disabling TLS compression, as it exploits TLS-level compression of requests.

Errata ID: 4894
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Élie
Date Reported: 2016-12-22

Section 2.2 says:

   STARTTLS and similar mechanisms are vulnerable to downgrade attacks,
   whereby the attacker simply removes the STARTTLS indication from the
   (unprotected) request.  This cannot be mitigated unless HSTS-like
   solutions are added.

Notes:

The second paragraph in Section 2.2 ("STARTTLS Command Injection Attack") should have been in Section 2.1 ("SSL Stripping") because it concerns the attack known as "SSL Stripping".

Note that Section 3.2 of RFC 7525 refers to Section 2.1 (and not 2.2) of this RFC, when speaking about lack of advertise support for TLS.

Report New Errata