Closed garethsb closed 5 years ago
garethsb
commented
5 years ago FWIW, it appears that in March 2016, OpenSSL 1.1 also removed CCM from its default cipher list for TLS v1.2, preferring e.g. GCM. See https://github.com/openssl/openssl/pull/783/commits/d771c5f00f370d4a968fb8db7ba84adec6d5253f.
If one trusts Wikipedia, it has a table of implementation support for various cipher suites: Comparison of TLS implementations - Encryption algorithms.
simonrankine
commented
5 years ago Hmm, the annoying thing is that the reason this is the default is it's easier to implement in a lightweight fashion on resource constrained hardware.
However, there may be some mileage in saying that clients have to support it, but servers just have to support an acceptable cipher suite, and then increasing the number of mandatory ciphers for clients.
garethsb
commented
5 years ago That motivation is understandable. I haven't evaluated cipher suite performance myself at all but in a quick search, the top two results that claim GCM is more efficient than CCM?
I'm not sure how much asymmetric requirements on servers and clients would help, as clients in this instance includes e.g. Node interaction with the Registration API?
garethsb
commented
5 years ago So far as I can tell from Microsoft's Cipher Suites in TLS/SSL, all of the TLS 1.2 cipher suites in the BCP-003-01 RECOMMENDED list have been supported in every version from Windows 7 through current Windows 10, although the default priority of these suites has varied over time. Of the TLS 1.2 cipher suites listed in BCP-003-01, it's actually only the REQUIRED cipher suite (TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8) that isn't supported.
The BCP-003-01 four highest priority TLS 1.2 suites can all be found near the top of the latest Windows 10 list:
These four ciphers are also found in the list returned from openssl ciphers -s -tls1_2 (OpenSSL 1.1.1b 26 Feb 2019, built on Ubuntu):
To determine support in other software-based implementations, look at Comparison of TLS implementations - Encryption algorithms (and Supported elliptic curves on the same page). Support for all four of those ciphers (with the secp256r1 curve) seems to be wide-spread.
Therefore, at the current time, all four would appear to be good candidates to be the single REQUIRED cipher suite, with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 usually being the highest priority.
However, we do not have any information about support for these cipher suites in highly resource-constrained devices.
Therefore, as discussed, it would be great to call for feedback from vendors on whether any of these cipher suites would be acceptable.
NEOAdvancedTechnology
commented
5 years ago TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (aka ECDHE-ECDSA-AES256-GCM-SHA384) has support in: AWS IoT message broker (although ECDHE-ECDSA-AES128-GCM-SHA256 is "recommended") Segger emSLL "emSSL can be used even on small microcontrollers" Inside Secure TLS Toolkit "can be configured to a minimal code footprint of 66 kB" Oryx CycloneSSL "lightweight TLS/DTLS implementation targeted for use by embedded application developers" wolfSSL "lightweight, portable, C-language-based SSL/TLS library targeted at IoT, embedded, and RTOS environments" MatrixSSL "open-source TLS/SSL implementation designed for custom applications in embedded hardware environments" SharkSSL Embedded SSL/TLS Stack EBSnet SSL " 'industrial strength' authentication and encryption for embedded communication and application devices." NetBurner IoT and embedded systems SDK for the NXP QorIQ LS1012A Low Power Communication Processor "optimized for battery-backed or USB-powered, space-constrained networking and IoT applications"
It is not supported by: Watson IoT Platform (no ECDSA ciphers)
Of note, the The Constrained Application Protocol (CoAP) RFC 7252 "Implementations in RawPublicKey mode MUST support the mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8"
NIST Special Publication 800-52 Revision 1 "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" has a SHALL for TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD for TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
garethsb
commented
5 years ago Thanks, that's useful information, @FOXNEOAdvancedTechnology, and has some reassuring overlap with the Wikipedia tables. What were your sources?
I found a Java 9 - Secure Socket Extension Provider - Enabled Cipher Suites list. It also includes the four cipher suites that @simonrankine prioritised in BCP-003-01, and indicates that they have been enabled by default since JDK 7 (CBC) or 8 (GCM).
NEOAdvancedTechnology
commented
5 years ago Good info on Java 9. My sources are the links.
garethsb
commented
5 years ago NIST Special Publication 800-52 Revision 1 "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" has a SHALL for TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD for TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
I now wonder if this is perhaps evidence that we might not want to be prescriptive at all. That document is in revision and NIST SP 800-52 Rev. 2 draft 2 no longer even recommends TLS_RSA_WITH_AES_128_GCM_SHA256, it has been moved to section D.1 Transition Period.
As far as I can see SP 800-52r2 does not indicate one required cipher suite at all.
garethsb
commented
5 years ago If we decide we must keep a required cipher suite in BCP-003-01, despite that it may result in regular updates being necessary, we should also consider cipher suites with RSA certs, such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. This was recommended in NIST SP 800-52r1 and is still found in NIST SP 800-52r2.
NIST SP 800-52r2 says that:
At a minimum, TLS servers conforming to this specification shall be configured with an RSA signature certificate or an ECDSA signature certificate.
But maybe it's best in BCP-003-01 just to refer to the NIST guidelines on cipher suite selection?
garethsb
commented
5 years ago Whoa.
FWIW, it appears that in March 2016, OpenSSL 1.1 also removed CCM from its default cipher list for TLS v1.2, preferring e.g. GCM. See openssl/openssl@d771c5f00f370d4a968fb8db7ba84adec6d5253f.
What I hadn't noticed until now was that the CCM ciphers weren't added until 1.1.0 either (though 8 months earlier in July 2015, openssl/openssl@e75c5a794e71baa3d76214be3ac8dc6e082e4a1a, and openssl/openssl@3d3701ea20ca36215e3af5ac090797cfec5fca2a for the CCM8 variants).
In other words:
andrewbonney
commented
5 years ago When resolving this, we should also resolve the line in the spec which states 'Servers SHALL support installation of multiple certificates". Windows (SChannel) does not support use of an RSA and ECDSA cert at the same time.
NEOAdvancedTechnology
commented
5 years ago Andrew, do you have a suggested resolution to the "multiple certificate" issue?
andrewbonney
commented
5 years ago I'd be happy to draft a PR covering both of these issues next week.
BCP-003-01 gives TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as the REQUIRED cipher suite for TLS v1.2.
We have implemented BCP-003-01 with a switchable secure comms implementation, and I now realise that on Windows, when using the Microsoft HTTP Server API (http.sys), that cipher suite is not supported on any test system.
This would appear to be because Windows Secure Channel (Schannel) does not implement that cipher suite. The list and default order of supported cipher suites depends on the version of Windows, but even on recent Windows 10, no AES-CCM cipher suites are provided.
This can be confirmed in the Schannel documentation at Cipher Suites in TLS/SSL (updated 31-May-2018, retrieved 30-Apr-2019).
While it is possible to use other server back-ends on Windows to support TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, is it reasonable for BCP-003-01 to prohibit Microsoft-based server implementations?
Note that Schannel does support other cipher suites on the BCP-003-01 TLS v1.2 recommended list including the next four highest priority: