Hugo Krawczyk <h...@ee.technion.ac.il> writes:
>there may be applications with legitimate reasons not to use FS.
It's not so much reasons not to use FS (well, there are some specialised cases
where people want to do that as well), it's reasons to reuse (EC)DH values.
This isn't something that was ever mentioned in the spec, it's what developers
have implemented themselves in order to deal with high-load conditions. This
also means that no matter what the spec might say in the future, if you've got
a developer facing a situation where they need 480% of available CPU to
service requests then they're going to do things like cache (EC)DH, regardless
of what the spec says. So making it a MUST NOT will end up as what someone on
PKIX once described as "workgroup posturing". Better to include an advisory
note on using it, for example what TLS-LTS says:
TLS-LTS mandates the use of cipher suites that provide so-called
Perfect Forward Secrecy (PFS), in which an attacker can't record
sessions and decrypt them at a later date. The PFS property is
however impacted by the TLS session cache and session tickets, which
allow an attacker to decrypt old sessions. The session cache is
relatively short-term and only allows decryption while a session is
held in the cache, but the use of long-term keys in combination with
session tickets means that an attacker can decrypt any session used
with that key, defeating PFS:
o Implementations SHOULD consider the impact of using session caches
and session tickets on PFS. Security issues in this area can be
mitigated by using short session cache expiry times, and avoiding
session tickets or changing the key used to encrypt them
periodically.
Another form of cacheing that can affect security is the reuse of the
supposedly-ephemeral DH value y = g^x mod p or its elliptic curve
equivalent. Instead of computing a fresh value for each session, some
servers for performance reasons compute the y value once and then reuse it
across multiple TLS sessions. If this is done then an attacker can compute
the discrete log value from one TLS session and reuse it to attack later
sessions:
o Implementations SHOULD consider the impact of reusing the y = g^x
mod p value across multiple TLS sessions, and avoid this reuse if
possible. Where the reuse of y is unavoidable, it SHOULD be
refreshed as often as is feasible. One way to do this is to
compute it as a background task so that a fresh value is available
when required.
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
