Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Peter Gutmann <[e-mail]>]

Hugo Krawczyk <[e-mail]> 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.