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 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
