Re: [TLS] "Spec Compliance" and the older TLS protocols

[Nikos Mavrogiannopoulos <[e-mail]>]

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