> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
