Subject: Re: [Uta] [Technical Errata Reported] RFC7457 (4403)

From: Ralph Holz <[email-masked]>
Date: Mon, 29 Jun 2015 11:26:32 +1000

Hi everyone,

I think this should be recorded as verified - peer-reviewed attack, valid
erratum.

Ralph

On 28/06/15 22:28, RFC Errata System wrote:> The following errata report
has been submitted for RFC7457,
> "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram
TLS (DTLS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7457&eid=4403
>
> --------------------------------------
> Type: Technical
> Reported by: Sebastian Schinzel <[email-masked]>
>
> Section: 2.7
>
> Original Text
> -------------
> 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.
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7457 (draft-ietf-uta-tls-attacks-05)
> --------------------------------------
> Title               : Summarizing Known Attacks on Transport Layer
Security (TLS) and Datagram TLS (DTLS)
> Publication Date    : February 2015
> Author(s)           : Y. Sheffer, R. Holz, P. Saint-Andre
> Category            : INFORMATIONAL
> Source              : Using TLS in Applications APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jun 2015 10:17:12 +0100

> I think this should be recorded as verified - peer-reviewed attack, valid

Done.

S.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>