Pregunta:
¿Por qué el NIST elimina y no actualiza la guía de TLS? ¿Qué es el reemplazo?
Drew Lex
2013-03-22 21:44:07 UTC
view on stackexchange narkive permalink

El documento Publicación especial 800-52 del NIST Directrices para la selección y el uso de implementaciones de seguridad de la capa de transporte (TLS) se retiró sin reemplazarlo por un documento más nuevo.

En Además, hay un artículo de Network World que menciona el requisito de TLS de autorización mutua en los sitios web del gobierno y la posible depreciación de TLS 1.0.

  • No tengo el documento original para referirse, pero ¿qué era tan atroz en este documento que requirió su desaparición? ¿Se está preparando el NIST para deshacerse de ciertas configuraciones de TLS?

  • ¿Cuáles son las implicaciones para el usuario federal en cuanto a que TLS avance?

No hay reemplazo para TLS. Así que dudo que TLS vaya a alguna parte (excepto quizás, finalmente, actualizarse a 1.2).
¿Por qué un solo documento caducado, que puede haber sucedido automáticamente, le hace sospechar esto?
Por lo que sabemos, este problema con la documentación en la red pública puede ser el resultado de recortes fiscales. Probablemente esté disponible en otros lugares, o la v2 se está revisando con retraso.
En "Publicaciones especiales archivadas" http://csrc.nist.gov/publications/PubsSPArch.html Sp800-52 es el único documento que no tiene "Reemplazado por:". Dudo que haya un corte automático.
En mi opinión, el mayor cambio que podría esperar es que exijan TLS 1.2 o algunos cambios en las suites de cifrado permitidas. Ciertamente no es un protocolo completamente nuevo.
@CodesInChaos: parece que tiene razón, este artículo lo dice: https://www.networkworld.com/news/2012/081512-nist-tls-261670.html
+1 Maremoto. Esta q tiene 30 visitas y sin un solo upvote Me hace pensar que se necesita una revisión para que atraiga a una audiencia más lógica. (por ejemplo, no suena tan alarmista y más riesgoso / lógico)
@DrewLex Hice modificaciones a su pregunta que pueden llamar más la atención sobre ella. Edite o revise según sea necesario.
Dos respuestas:
Ryan Fisher
2014-05-21 23:56:13 UTC
view on stackexchange narkive permalink

Tomó casi un año, pero NIST ha publicado este boletín que explica la actualización y también proporciona el documento actualizado para SP 800-52 Revisión 1.

La respuesta a su pregunta se expresa en el boletín:

NIST publicó la versión original de SP 800-52 en 2005, pero la retiró en marzo de 2013 porque la directriz aún no había sido actualizado en función de las nuevas versiones de TLS y vulnerabilidades conocidas. Esta nueva publicación es la versión final de SP 800-52 Rev.1, que incorpora comentarios públicos a la versión preliminar realizada en el otoño de 2013.

Entre los cambios en SP 800-52 se encuentran las recomendaciones. que los servidores y clientes gubernamentales pasen a TLS 1.1 y 1.2. También recomienda que adopten conjuntos de cifrado con algoritmos aprobados por NIST para admitir la seguridad de 112 bits y superior.

mr.spuratic
2013-03-23 04:30:14 UTC
view on stackexchange narkive permalink

Actualizado: consulte la respuesta de Ryan Fisher a esta pregunta, SP800-52 revisión 1 se publicó más tarde y es el doble del tamaño de la versión original de 2005. Fue retirado porque carecía de información sobre las versiones actuales de TLS y problemas de seguridad conocidos (es decir, para evitar desinformación, hasta que pudiera actualizarse).


No fue " retirado "(o" caducado "), fue" retirado ", sin duda una distinción semántica menor. El NIST tiene la siguiente generalidad para decir sobre eso:

Esta página contiene una lista de Publicaciones Especiales (SP) retiradas que han sido reemplazadas por un SP actualizado o ya no se admite y no se lanzó una versión actualizada.

Dado que es no hubo ( evidente) sucesor, es posible que no ya es compatible. Vale la pena señalar que su razón de ser no tiene menos de 17 años.

Sugiero que la principal motivación es la eliminación (selectiva) de uno o más de 3DES / TDEA, MD5 (que el NIST hace mucho que no le gusta) o SHA-1. La declaración oficial es que 3DES es válida hasta 2015 (o 2030), TLSv1.1 elimina el TLSv1.0 a obligatorio > cifrar TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA a favor de TLS_RSA_WITH_3DES_EDE_CBC_SHA, y TLSv1.2 lo elimina a favor de TLS_RSA_WITH_AES_128_CBC_SHA.

Las versiones de TLS posteriores a TLSv1.0 siguen siendo compatibles con MD5, pero dado que SHA-1 está obsoleto y debe desaparecer para determinados fines este año, son claras ventajas de TLSv1.1 y versiones posteriores, incluida una menor dependencia de MD5 / SHA-1 y una mejor compatibilidad con funciones de cifrado o hash arbitrarias mediante extensiones.

(Entonces, lo que CodesInChaos dijo, pero con más saludos, conjeturas e hipervínculos ;-)



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...