Con TLS 1.2, el servidor primero necesitaba informar al cliente dentro del mensaje ServerKeyExchange sobre los parámetros del grupo DHE que admite. Sólo entonces el cliente podría actuar sobre estos. Con TLS 1.3, el cliente elige a partir de un conjunto de grupos nombrados desde el inicio. Dado que el cliente ahora elige los grupos en lugar del servidor, el intercambio de claves puede comenzar inmediatamente (toda la información se conoce desde el inicio), lo que corta un RTT completo del protocolo de enlace, lo que resulta en un mejor rendimiento.
Por supuesto, en teoría, uno todavía podría tener grupos personalizados de esta manera, solo que el cliente define estos grupos esta vez y no el servidor. No puedo encontrar ninguna información específica sobre por qué se eliminaron los grupos personalizados, pero pareció ocurrir durante una reunión intermedia a mediados de 2014 basada en este mensaje en la lista de correo TLS . No puedo encontrar ninguna información sobre esto en la reunión oficial en 03/2014 ni en la siguiente en 07/2014 .
Pero, algo de información en el documento Registros indiscretos: puertas traseras persistentes de Diffie-Hellman
en TLS a partir de 2016 podría apuntar en la dirección correcta. Este documento analiza las puertas traseras que se pueden negar utilizando grupos DH personalizados y en VII. Discusión A. Estrategias de mitigación se discuten varias estrategias para prevenir tales puertas traseras, como deshabilitar el DHE por completo o usar solo grupos de DH bien conocidos (con nombre) similares a lo que se hace con ECC. Si eliminar DHE por completo no es una opción, tener la forma más fácil de manejar este problema es tener un conjunto fijo de parámetros DHE con nombre.