!!! Overview
[{$pagename}] ([DHE]) is a modification of the [Diffie-Hellman key-exchange] that used __static keys__.

A cryptographic key is called ephemeral if it is generated for each execution of a [Key-Exchange] process. 

In some cases ephemeral keys are used more than once, within a single session (e.g., in broadcast applications) where the sender generates only one ephemeral key pair per message and the private key is combined separately with each recipient's [Public Key].

[{$pagename}] is a modification of the [Diffie-Hellman key-exchange] that used __static keys__.

[{$pagename}] is defined within [RFC 5246].


!! Negotiated Finite Field [{$pagename}] Parameters for [Transport Layer Security] ([TLS])
Traditional [TLS 1.2] [RFC 5246] offers a [{$pagename}] ([DHE]) [key-Exchange] mode that provides forward secrecy for the connection.  The client offers a cipher suite in the [ClientHello] that includes [DHE], and the server offers the client group parameters generator g and modulus p.  

If the client does not consider the group strong enough (e.g., p is too small, p is not prime, or there are small subgroups that cannot be easily avoided) or if it is unable to process the group for other reasons, the client has no recourse but to terminate the connection.

Conversely, when a TLS server receives a suggestion for a [DHE] [Cipher Suite] from a client, it has no way of knowing what kinds of DH groups the client is capable of handling or what the client's security requirements are for this key exchange session.  

For example, some  widely distributed TLS clients are not capable of DH groups where p > 1024 bits.  Other TLS clients may, by policy, wish to use DHE only if the server can offer a stronger group (and are willing to use a non-PFS ([Perfect Forward Secrecy]) [key-Exchange] mechanism otherwise).  The server has no way of knowing which type of client is connecting but must select DH parameters with insufficient knowledge.

Additionally, the DH parameters selected by the server may have a known structure that renders them secure against a small subgroup attack, but a client receiving an arbitrary p and g has no efficient way to verify that the structure of a new group is reasonable for use.
  
[RFC 7919] modification to [TLS] solves these problems by using a section of the "[Supported Groups Registry]" (renamed from "EC Named Curve Registry" by this document) to select common DH groups with known structure and defining the use of the "elliptic_curves(10)" extension for clients advertising support for [DHE] with these groups.  [RFC 7919] also provides guidance for compatible peers to take advantage of the additional security, availability, and efficiency offered.

!! [Elliptic Curve Diffie-Hellman Ephemeral] ([ECDHE])
[TLS] also supports [Elliptic Curve Diffie-Hellman Ephemeral] ([ECDHE]) [Key-Exchanges] as described in [RFC 4492]


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]