If you want to lawyer up on this, I think that the official interpretation is that those RFCs were obsoleted by RFC 5246 and so if you support 5246, you can do what it says and not what the older specs say. I don't think that anyone will fault you if you decide to burn all traces of DES from your stack. It's your stack, and there's enough AES to go around.
On 4 March 2017 at 10:32, Bradford Wetmore <[email protected]> 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. > > Ignoring the data limits approach, the degree of vendor/implementation > response to these ciphersuites varies: > > 1. default enabled/available ciphersuites remain the same, > > 2. reduce the ciphersuite priority, but the ciphersuites are still > enabled/available by default, > > 3. "disable" the ciphersuites by default, but allow for reenabling through > API or system configuration, > > 4. remove the ciphersuites from the binary (e.g. via conditional > compilation/packaging), > > 5. completely remove all trace from the library's source. > > 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. > > Would 4-5 be considered technically non-compliant implementations? > > Thanks, > > Brad > > [SWEET32] https://sweet32.info/ > [RFC2119] https://www.ietf.org/rfc/rfc2119.txt > [RFC2246] https://www.rfc-editor.org/rfc/rfc2246.txt > [RFC4346] https://www.rfc-editor.org/rfc/rfc4346.txt > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
