Here at wolfSSL we love TLS 1.3, but we also know there are other protocols out there such as: DTLS, QUIC, SSH, MQTT and Noise. In this post we will compare and contrast TLS 1.3 against Noise and provide some notes about FIPS-140 and post-quantum cryptography.
Noise itself is NOT a protocol per se; it is a protocol framework (here lies the biggest difference between TLS 1.3 and Noise). When using TLS 1.3 the connection will be authenticated, confidential, and have integrity. It is quite simple and efficient to get these properties. All of wolfSSL’s example server and client applications that do TLS 1.3 are just a few hundred lines of code and the simplest can easily be under 100 lines (found here:https://github.com/wolfSSL/wolfssl-examples/tree/master/tls). Contrast that with the requirement that you need to design your own Noise-based protocol depending on the security properties that you desire, and suddenly Noise looks a bit more challenging than TLS 1.3. Expertise is required! See section 7.5 of https://noiseprotocol.org/noise.html to see the fundamental patterns that can be used.
The next biggest difference is authentication. TLS usually requires the server to have an X.509 certificate so the client can verify the identity of the server. The server’s identity is bound to the public key via the certificate and is verified by proving possession of the private key to the client. The Noise Framework does not support identity verification; it leaves that to the application. However, it does allow for using static encryption keys which then ensures that each side is talking to the same party they were talking to in the past. And again, you must design or use the correct pattern to achieve this goal and then design identity verification into your application.
TLS 1.3 standardizes the cryptographic algorithms and NIST gives guidance on which algorithms to use in it. As a result, it is easy to stay in compliance with FIPS-140. For example, if you simply use wolfSSL’s defaults in our FIPS-certified product, you will be fine. On the other hand, for Noise, NIST has given no guidance so you are on your own when you design your protocol or pick your patterns.
Can you do post-quantum cryptography in TLS 1.3 today? Yes! There are private use code points for the Supported Groups Extension and Signature Algorithm Extension. However, once post-quantum algorithms are standardized, standard codepoint and OIDs should quickly follow. The mechanics and cryptographic artifacts of post-quantum signature schemes and KEMs (key encapsulation mechanism) fit quite nicely into the TLS 1.3 handshake and X.509 certificate PKI. For more details, you can read our documentation about post-quantum TLS 1.3 in wolfSSL at https://www.wolfssl.com/documentation/manuals/wolfssl/appendix07.html. What about the Noise Framework? The short answer is no. The protocol framework relies on the “non-interactiveness” of the Diffie-Hellman key exchange protocol and KEMs are interactive! There are no known post-quantum non-interactive key exchange algorithms as of the time of this writing. However, research into different possibilities is ongoing and the Noise Protocol framework could eventually evolve into supporting post-quantum algorithms. For example, please see https://eprint.iacr.org/2022/539.pdf.
Our conclusion is that if TLS 1.3 can get you what you need, then keep it simple and use TLS 1.3.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.