Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan <[e-mail]>]

> 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a client that supports TLS 1.3? Why doesn't the already-standardized downgrade SCSV mechanism work for those cases?

The attack we’re protecting against is the following:
- a TLS 1.3 client sends a client hello and the MitM changes the version field to TLS 1.0 (say) with some weak signature-based ciphersuite (e.g. DHE/DHE-EXPORT + AES-CBC)
- for good measure, the MitM also drops any protocol extensions that are inconvenient (e.g. FFDHE/extended master secret/…)
- the TLS 1.3 server thinks the client does not support TLS 1.3 and so falls back to the requested protocol
- in TLS 1.0, the server signature does not include the version, ciphersuite, or extensions, so the client accepts the server flight and computes a master secret and finished message

Now, the crucial step is that if the downgraded protocol is so weak that the attacker can (with some computational effort) forge the server’s finished message, the connection will complete.
There are some instances in which the attacker may be able to achieve this: by breaking SHA-1, or a weak DHE group, by redoing some variation of the triple handshake attack, or by 
exploiting some software bug in a rarely used low-preference ciphersuite. Note that the client did not fallback, the server did, so Fallback SCSV does not apply.

The key observation is that downgrade protection in TLS 1.2 (and below) relies on the Finished MAC, but the elements that go into computing this MAC (DH group, hash algorithm)
are themselves negotiated within the handshake and may be downgraded. This is a fundamental protocol limitation that is addressed by TLS 1.3. Now, our goal is to protect TLS 1.3 itself
from older protocol versions.

From an academic researcher’s viewpoint, there are two reasons to suggest such a countermeasure. 
1) Historically, signalling the ciphersuite in the server signature would have prevented high-profile attacks like FREAK, Logjam, and the cross-protocol attack between ECDHE/DHE in 2012.
    I agree that trying to protect from potential attacks may seem speculative, but the idea is to provide some additional protection against future attacks even if all TLS clients and servers are not immediately patched.
2) Looking forward, a number of researchers would like to give a strong security theorem for TLS 1.3, but at present we would not be able to guarantee security for any TLS 1.3 implementation 
    that also implements older protocol versions, because we would then also have to prove secure all the ciphersuites used in these old versions (some of which are certainly broken from the
    point of view of provable security). For our proofs, we’d like nothing better than to be able to assume that older versions of TLS have been disabled, but I guess that is unlikely to happen soon.


It would have been nice not to rely on a “clever” trick, but we could not see how else to add any mechanism that could itself not be deleted by an attacker in older versions. 
TLS has a long history of signalling downgrades in strange ways.  The RSA PMS still includes the protocol version due to an old SSL3->SSL2 downgrade attack. 
The Fallback SCSV is a signal encoded in a bogus ciphersuite, because SSL3 does not support extensions. 
These are all unfortunate hacks, made necessary by the limited handshake protections in older versions.
The chief benefit is that we can then protect clients and servers that implement our brand new protocol version.

Best,
Karthik



> 
> Cheers,
> Brian
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls