TLS 1.3がカスタムDHEグループを廃止するのはなぜですか？
TLS 1.3仕様の2番目のドラフト によると、カスタムDHグループは非推奨になりました。ご存じのとおり、ハードコードされたDHグループは、遡及的な復号化を可能にする 事前計算攻撃 に対して脆弱です。 TLS 1.3はキー交換のためのDHを完全に廃止しないので、これは標準グループ（Oakleyグループなど）にフォールバックすることを意味すると思います。これを念頭に置いて、TLS 1.3はなぜカスタムDHグループを廃止するのですか？逆に標準グループを非推奨にし、ECCに道を譲るためにすべてのDH鍵交換を非推奨にしないのはなぜですか？
TLS 1.2では、サーバーは最初に、サーバーがサポートするDHEグループのパラメーターについてServerKeyExchangeメッセージ内でクライアントに通知する必要がありました。そうして初めて、クライアントはこれらに対処できます。 TLS 1.3では、クライアントは最初から一連の名前付きグループから選択します。クライアントがサーバーではなくグループを選択するようになったため、キー交換をすぐに開始でき（すべての情報は最初からわかる）、ハンドシェイクから完全なRTTが削減され、パフォーマンスが向上します。
もちろん、理論的には、この方法でカスタムグループを設定することもできますが、今回はクライアントがサーバーではなくこれらのグループを定義するだけです。カスタムグループが削除された具体的な情報は見つかりませんが、2014年半ばの中間会議中に TLSメーリングリストのこのメッセージ に基づいて発生したようです。 2014年3月の公式会議 にも 2014年7月の次の会議 にもこれに関する情報はありません。
しかし、2016年の論文 Indiscreet Logs：Persistent Diffie-Hellman Backdoors in TLS の一部の情報は、正しい方向を示している可能性があります。このペーパーでは、カスタムDHグループを使用した拒否可能なバックドアとVIIについて説明します。ディスカッションA.軽減戦略DHEを完全に無効にする、またはECCで行われるものと同様の既知の適切な（名前付き）DHグループのみを使用するなど、このようなバックドアを防ぐためのさまざまな戦略が議論されます。 DHEを完全に削除することができない場合は、名前付きDHEパラメータの固定セットがあると、この問題を処理する最も簡単な方法のように見えます。