Creo que mezcla el cifrado oportunista como se describe en estos borradores y STARTTLS.
STARTTLS tiene una semántica claramente definida sobre cómo deben verificarse los certificados (ver RFC6125) y la mayoría de los Agentes de Usuarios de Correo (MUA) implementan estas validaciones al conectarse a un Agente de Transporte de Correo (MTA). Por lo tanto, debe aceptar explícitamente una huella digital específica de un servidor si el certificado está firmado por una CA desconocida. La mayoría de los MTA ofrecen formas de deshabilitar estas comprobaciones de validación, con la argumentación de que el TLS no validado ayuda contra el monitoreo pasivo, por lo tanto es mejor que ningún TLS.
Pero, el modelo de seguridad del correo (SMTP) es totalmente diferente del HTTP. SMTP es un protocolo de salto por salto con al menos en MTA entre la MUA de origen y destino. No hay cifrado de extremo a extremo (es decir, de MUA a MUA), sino solo salto por salto. Esto significa que cualquier MTA intermedio puede ver y modificar los correos electrónicos en texto sin formato, incluso si la conexión a este MTA está protegida por TLS. Entonces, si necesita privacidad con SMTP, necesita cifrar el cuerpo del correo usted mismo: para eso están PGP y S / MIME.
En su lugar, HTTP proporciona una conexión de extremo a extremo entre las partes y HTTPS, por lo que ofrece un cifrado de extremo a extremo. No hay una capa de seguridad adicional definida (por ejemplo, similar a PGP o S / MIME), por lo que su privacidad depende únicamente de la implementación adecuada de TLS.
Eche un vistazo a la sección sobre consideraciones de seguridad en los RFC a los que hizo referencia. Ambos afirman claramente que solo protegen contra el monitoreo pasivo, que son vulnerables a los ataques de intermediarios y que los creadores de navegadores no deben proporcionar una interfaz de usuario que pueda sugerir una protección comparable a HTTPS.
Y sobre sus quejas sobre el "cartel" asociado con HTTPS: No hay nada inherente con TLS / HTTPS que necesite tal "cartel". Pero, lo que necesita es una forma de validar la identificación (certificado) presentada por el par, ya que de lo contrario sería vulnerable a los ataques del hombre en el medio (activo). Históricamente, esta validación se ha implementado al tener un conjunto fijo de anclas de confianza en los navegadores y comenzar desde allí para validar el certificado. Si tiene otra forma confiable de verificar el certificado de servidores, puede usarlo, pero al final no elimina la necesidad de algún tipo de anclajes de confianza, sino que solo lo reemplaza con otros anclajes de confianza. Al igual que con DANE, donde necesita DNSSec que nuevamente necesita CA confiables para firmar las entradas de la raíz del DNS y construir una cadena de confianza desde allí para verificar las entradas del DNS que incluyen el certificado.
No sugeriría, que la forma actual con 100s de CA de raíz totalmente confiables dentro del navegador es la forma en que debemos continuar. Pero al menos proporciona la seguridad esperada en la mayoría de los casos. Por lo tanto, no recomendaría reemplazarlo por algo mucho peor, es decir, uno de estos borradores que proporciona cifrado sin identificación del par. Ni siquiera recomendaría implementar esto como una opción dentro del navegador, porque el usuario promedio no podrá entender las diferencias entre los distintos niveles de seguridad.