Hi, Brad What Martin said. Additionally, I work for a vendor that has to really “lawyer up” sometimes.
So if RFC 2246 says “MUST implement X” and your code doesn’t implement X, just don’t claim compliance with RFC 2246. You can still have TLS 1.0 code for BC. In general, people looking for statements about compliance will be fine with only claiming compliance with the latest and greatest as long as the latest and greatest is also implemented in their “other side”. So TLS 1.2 is likely good enough. As for what “MUST implement” means, there have been very long-winded discussions about this over the years. The general agreement seems to be “must implement but not necessarily enabled”. So if your implementation has TLS_RSA_WITH_3DES_EDE_CBC_SHA and it’s disabled by default and there’s some way to enable it, you can still claim RFC 4346 compliance. Yoav > On 4 Mar 2017, at 1:32, Bradford Wetmore <bradford.wetm...@oracle.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
