In May 2015, a team of cryptographers dropped a bombshell paper called Imperfect Forward Secrecy. It showed that a nation-state adversary could plausibly break 1024-bit Diffie-Hellman by precomputing a single massive table for one commonly-used prime, then cracking any session that used that prime in near-real-time. The attack, nicknamed Logjam, ripped through the TLS ecosystem: an estimated 8.4% of the top million HTTPS sites, and the majority of IPsec VPNs, shared one of just a few 1024-bit groups. RFC 7919 is the cleanup crew.

The problem it solves. Before RFC 7919, TLS's finite-field Diffie-Hellman (DHE) had a bizarre asymmetry with its elliptic-curve cousin (ECDHE). For ECDHE, the client advertised which named curves it supported and the server picked one. For DHE, the server just sent whatever group parameters it felt like — often ancient, weak, or unvalidated. The client had no way to say "I refuse groups smaller than 2048 bits" without breaking the handshake, and no way to know if the server's prime was a well-analyzed safe prime or something a nervous sysadmin generated with OpenSSL at 2am.

The design. RFC 7919 does two elegant things:

• It reuses the existing supported_groups extension (previously called elliptic_curves, and renamed by this RFC precisely so it could hold both curves and FFDHE groups) to let clients advertise acceptable DH groups by codepoint.
• It defines a fixed catalog of vetted groups: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, and ffdhe8192. Each prime p is a safe prime of the form p = 2q + 1 where q is also prime, with the high 64 bits set to all-ones and the fractional part of the prime derived from the digits of e — a "nothing up my sleeve" construction that proves the author didn't backdoor the group.

Why the fixed catalog matters. This is the philosophical pivot. For decades, the cryptography folklore held that using a unique DH group per server was safer because attackers had to work harder for each target. Logjam inverted that intuition: the precomputation attack scales so aggressively that any 1024-bit group is dead regardless of who generated it, and at 2048+ bits the per-group work is astronomical whether one server or a million share it. Shared, well-analyzed groups are actively better — you get more scrutiny on the parameters and no risk of a homebrew prime with a subtle flaw.

Why it still matters. TLS 1.3 (RFC 8446) formalized the win: it removes custom DH groups entirely and mandates the RFC 7919 named groups for FFDHE. If you inspect a modern TLS 1.3 handshake and see ffdhe2048 flying past, you're looking at RFC 7919's catalog. The RFC also quietly established a pattern reused across modern protocol design — SSH (RFC 8268) and IKEv2 have both moved toward named, vetted groups rather than negotiated custom parameters.

An operational footnote. The RFC includes a small but crucial requirement: if a client advertises FFDHE groups and the server has no group in common, the server MUST either fall back to a non-DHE cipher suite or send insufficient_security. It must not silently send a legacy weak group. This closes a downgrade path that would otherwise have made the extension useless.