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

From: Bradford Wetmore <[email-masked]>
Date: Fri, 3 Mar 2017 15:32:19 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 5 Mar 2017 21:55:26 +1100

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-masked]> wrote:
> An interpretation question for our older RFCs, in particular TLSv1 [RFC2246]
> and TLSv1.1 [RFC4346] in the context of recent developments [SWEET32].
>
> 3.  "disable" the ciphersuites by default, but allow for reenabling through
> API or system configuration,
>
> 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.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Mar 2017 14:04:09 +0200

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 <[email-masked]> 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
> 
> Ignoring the data limits approach, the degree of vendor/implementation response to these ciphersuites varies:
> 
> 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),
> 
> 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.
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 06 Mar 2017 09:41:16 +0100

>     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.

> [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