On Fri, 2017-03-03 at 15:32 -0800, Bradford Wetmore wrote: > An interpretation question for our older RFCs, in particular TLSv1 > [RFC2246] and TLSv1.1 [RFC4346] in the context of recent > developments > [SWEET32]. > > In particular, likely for minimal interoperability reasons, specific > 3DES-based ciphersuites must be implemented in TLS: > > TLS 1.0 > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > > TLS 1.1 > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
I do not think the TLS 1.0 MUST requirement for a mandatory ciphersuite was ever implemented at the time TLS 1.0 was the latest protocol. None of the browsers of the time supported TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. TLS 1.1 was modified to reflect the actual situation as you see above. > So, strictly speaking from a RFC point of view (not practical or > security POV, those are different questions), what do these "MUST > implement" statements mean in order for an implementation to still > be > considered "spec-compliant" in the post-SWEET32 era. 1-2 above? 1- > 3? > [RFC2119] isn't clear on whether 3 would be ok. Spec compliance at the time of TLS 1.0 and TLS 1.1 was interoperation with the available browsers and servers. The spec itself didn't result to guaranteed interoperability. regards, Nikos _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
