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
