On 29/06/15 02:26, Ralph Holz wrote: > Hi everyone, > > I think this should be recorded as verified - peer-reviewed attack, valid > erratum.
Done. S. > > 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 protected]> >> >> 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 >> > > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
