support for TLS_PSK_WITH_NULL_SHA256

[lomer2]

Hi,
I would like to add support to TLS_PSK_WITH_NULL_SHA256 cipher suite.
Is this a planned feature?
is it more to it than to add an appropriate line in the _nx_crypto_ciphersuite_lookup_table table?
Thanks!

[fdesbiens]

Hi @lomer2! Thank you for reaching out.

This is not on the roadmap right now. I am not a hardcore TLS guy so I am not sure how complicated implementation would be. I will discuss this with the team and come back to you.

[fdesbiens]

Hi @lomer2.

I appreciate your patience. The core team discussed your request last week. Unless we are mistaken, it appears you want to use NetX Secure TLS 1.2 with a PSK and zero encryption to achieve some authentication and integrity checking only on TLS messages, leaving payloads unencrypted in plaintext.

This use case resembles IPSec AH mode. Based on industry practices, NIST, and other authoritative sources, it should be avoided. It is completely eliminated in TLS 1.3.

So, our initial reaction would be to decline your request. We have trouble justifying why we would add such a weak security profile to the code base. That said, feel free to share more information about your use case and requirements. This could lead us to reconsider. I will leave the issue open for now as we have this conversation.

Best Regards,

Frédéric

[lomer2]

Thanks @fdesbiens,
I understand the reasoning, I will explain the use case and see if it makes sense.
The use case in mind is an automotive sensor communicating with the vehicle's (OEM-defined) main controller over an internal in-vehicle network. The security requirements over this communication line require authentication only (no requirement for encryption). The main challenge with ECDSA/RSA-based cipher suites is the provisioning of the certificates during manufacturing, which is the reason we prefer using a PSK. Among the PSK ciphersuites, TLS_PSK_WITH_NULL_SHA256 is the only one that is supported by the OEM stack.
While the downsides of using the TLS_PSK_WITH_NULL_SHA256 are understood, we believe it is justified in this case.
Thanks!
Omer

[fdesbiens]

Thank you for those details, @lomer2.

I will bring this information back to the team for further discussion.

From a long-term support perspective, I wonder if there could be better alternatives to fulfil your requirements given the cipher suite is removed in TLS 1.3.