Conform to NIST requirements for ephemeral keys in libssl for ECDHE_ cipher suites

NEW
Unassigned

Status

NSS
Libraries
8 years ago
8 years ago

People

(Reporter: briansmith, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Currently, the server side of libssl caches ECDHE keys and reuses them. NIST guidelines [2] require ephemeral keys to be used at most once and to be generated at the time of use. The NSA Suite B profile for TLS [2] presumably depends on this definition of ephemeral. Further, (EC)DHE_* cipher suites are intended for applications that want perfect forward secrecy, which is at odds with this kind of key reuse.

[1] http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf:

"1. An ephemeral private key shall be used in exactly one key establishment transaction, with one exception: an ephemeral private key may be used in multiple DLC Key Transport transactions that are transporting identical secret keying material simultaneously (or within a short period of time; see Section 7). After its use, an ephemeral private key shall be zeroized."

"2. An ephemeral key pair should be generated as close to its time of use as possible. Ideally, an ephemeral key pair is generated just before the ephemeral public key is transmitted."

[2] http://tools.ietf.org/html/rfc5430

(Incidentally, over the summer I started a proposal for a new key exchange mechanism for TLS--with corresponding cipher suites--that allows the client and server to explicitly and securely agree on caching of (EC)DHE parameters across connections, in order to enable higher-level optimizations similar to False Start, Snap Start, and this optimization while still allowing for a reasonable expectation of forward secrecy. I hope to finish it and publish it sometime soon. I think new cipher suites are the way to go for this type of optimization.)
You need to log in before you can comment on or make changes to this bug.