我认为使用预定义组的原因在您的参考页面上得到了明确的回答：

运营商应使用 IETF 在RFC 7919中推荐的预定义 DH 组 ffdhe2048、ffdhe3072 或 ffdhe4096，而不是使用预配置的 DH 组，或使用“openssl dhparam”生成自己的组。 这些组经过审计，可能比随机生成的组更能抵抗攻击。

我与 Logjam 攻击有关，建议不要使用 1024 位或更低的预定义 DH 组，因为这种密钥大小被认为是当今攻击者可以接触到的，对于频繁使用的密钥可能值得付出努力。但是更大的密钥大小还没有被认为是攻击者可以触及的。

我认为 RFC 7919 背后的想法更多是关于互操作性。

虽然自定义 DH 组服务器端可能更安全，并且不会受到影响，例如，如果 NSA 设法破解更常用的组之一，它会将健全性检查工作放在客户端上。这些客户可能对什么构成一个理智和安全的群体有截然不同的想法。例如，他们可能对可接受的位长度有不同的想法。并且没有反向渠道。客户端无法提前告诉服务器“我将接受某某组......”，之后也无法告诉服务器“对不起，我不会与那个组合作！” 客户端会失败，而服务器永远不会知道。互操作性的噩梦。

现在 RFC7919 尝试做的是使用椭圆曲线 DH 已经存在的相同逻辑，并将其用于常规（“MODP”、“有限域”）DH。

这样，客户至少可以提前说“我会接受这样那样的团体......”并且少数进入IANA 团体注册机构的团体可以由公众检查/审查。

RFCs 摘要列出了理由：

抽象的

在传输层安全 (TLS) 握手期间，传统的基于有限域的 Diffie-Hellman (DH) 密钥交换存在许多安全性、互操作性和效率缺陷。这些缺点是由于不清楚 TLS 服务器应该提供哪些 DH 组参数以及客户端应该接受哪些参数。本文档通过使用 TLS“支持组注册表”（本文档从“EC 命名曲线注册表”重命名）的一部分来建立具有已知结构和机制的通用有限域 DH 参数，为兼容对等体提供了这些缺点的解决方案。同侪协商对这些团体的支持。

本文档更新了 TLS 版本 1.0 (RFC 2246)、1.1 (RFC 4346) 和 1.2 (RFC 5246)，以及 TLS 椭圆曲线加密 (ECC) 扩展 (RFC 4492)。

2017-02-03 更新：论文

我刚刚找到了这篇论文：

• Cryptology ePrint 存档：报告 2016/999：2016-10-17，轻率日志：TLS 中的持久 Diffie-Hellman 后门

他们抽象地说，由于性能下降，客户端通常不会在运行时检查参数。

因此，在这里定义、完整性检查和命名一些有限域 DH 组是有意义的。（至少比根本不验证更有意义。）