Mozillaが定義済みのDHEグループを推奨するのはなぜですか？
2016-10-31日付の改訂 で、Mozillaはサーバー側TLSの推奨をランダムなDHグループの生成から RFC 7919 で公開されたもの。 Mozillaの主張：
これらのグループは監査され、ランダムに生成されたグループよりも攻撃に対してより耐性がある可能性があります。
公開されたDHグループを使用していませんか Logjam 反対ですか？
事前定義されたグループを使用する理由は、参照ページで明確に回答されていると思います。
事前設定されたDHグループを使用するか、「openssl dhparam」で独自のDHグループを生成する代わりに、オペレーターは、IETFが RFC 7919 で推奨する事前定義されたDHグループffdhe2048、ffdhe3072、またはffdhe4096を使用する必要があります。 これらのグループは監査され、ランダムに生成されたグループよりも攻撃に対する耐性が高い可能性があります。
Logjam攻撃に関連して、1024ビット以下の事前定義されたDHグループを使用しないことをお勧めしました。このキーサイズは、今日の攻撃者の手の届く範囲にあると考えられ、頻繁に使用されるキーには努力する価値があるからです。しかし、より大きなキーサイズは、攻撃者の手の届く範囲にはまだ考慮されていません。
RFC 7919の背後にある考え方は、相互運用性に関するものだったと思います。
カスタムDHグループのサーバー側は潜在的に安全性が高く、影響を受けません。 NSAは、より一般的に使用されるグループの1つをクラックし、クライアントに健全性チェックの労力を費やします。そして、これらのクライアントは、正気で安全なグループを構成するものについて、まったく異なるアイデアを持っている可能性があります。たとえば、受け入れ可能なビット長については異なる考えがあるかもしれません。バックチャネルはありませんでした。クライアントは、サーバーに事前に伝える方法がありませんでした「私はそのようなグループを受け入れます...」 およびその後サーバーに通知する方法がない「申し訳ありませんが、そのグループでは機能しません！」クライアント失敗するだけで、サーバーはそれを知りませんでした。
RFC7919がやろうとしていることは、楕円曲線DHにすでに適用されているのと同じロジックを使用し、それを通常の（「MODP」、「有限フィールド」）DHに使用することです。
そうすれば、クライアントは少なくとも前もって言うことができます「私はそのようなグループを受け入れます...」そして、それを作る少数のグループ IANAグループレジストリ は、一般ユーザーが確認/確認できます。
RFCs Abstract はその根拠を示しています。
概要
トランスポート層セキュリティ（TLS）ハンドシェイク中の従来の有限フィールドベースのDiffie-Hellman（DH）鍵交換は、多くのセキュリティ、相互運用性、および効率の欠点の影響を受けます。これらの欠点は、TLSサーバーが提供し、クライアントが受け入れる必要のあるDHグループパラメーターが明確でないことから生じます。このドキュメントでは、TLSの「サポートされているグループレジストリ」（このドキュメントでは「EC Named Curve Registry」から名前が変更されています）のセクションを使用して、既知の構造とメカニズムを持つ共通の有限フィールドDHパラメータを確立することにより、互換性のあるピアのこれらの欠点の解決策を提供します。これらのグループのサポートについて交渉する仲間。
このドキュメントは、TLSバージョン1.0（RFC 2246）、1.1（RFC 4346）、および1.2（RFC 5246）、ならびにTLS Elliptic Curve Cryptography（ECC）拡張（RFC 4492）を更新します。
アップデート2017-02-03：紙
私はこの紙を見つけました：
- Cryptology ePrint Archive：Report 2016/999：2016-10-17、 Indiscreet Logs：Persistent Diffie-Hellman Backdoors in TLS
彼らは、パフォーマンスヒットのため、クライアントは通常、実行時にパラメーターをチェックしないと抽象的に言います。
したがって、いくつかの有限フィールドDHグループの定義、健全性チェック、および名前付けは、ここでは理にかなっています。 （少なくとも、まったく検証しないよりも意味があります。）