In specific implementation we're using TLS 1.0, open ssl 0.9.8 but i'm referring to RFC 5246.
For performance reasons, I'm being asked if we can use TLS without encryption. The hope is that the perfomance cost of using TLS will be less. The implementation will retain authentication and integrity of communication, but there will be no confidentiality.
The RFC does seem to say in Appendix C that where we see 'SHA' in a cipher suite we should understand HMAC-SHA1. So I'd interpret the NULL_SHA in e,g, TLS_RSA_WITH_NULL_SHA as HMAC-SHA1 rather than a digest. In Section 184.108.40.206 we see that even with a NULL cipher a mac can be calculated. So in theory we can get integrity from TLS without encryption.
However, nobody seems to be using TLS this way, existing TLS tools (e.g. socat, openssl in default configurations) do not seem to want to negotiate null ciphers,
So my questions
- Can TLS assure authentication and integrity with a NULL cipher ? Is this a reasonable optimisation to make, it seems to hold water but i'm not confident..
- What is this optimisation likely to be worth ? The SHA must still be computed and HMAC'd even if AES-CBC is no longer calculated. I'm not sure how SHA compares to AES, can someone estimate what % reduction in operations there will be to calculate TLSCiphertext ? e.g could be we expect a 50% reduction in an SSL_write / SSL_read comapred to a TLS session with AES 256 encryption
Then some less important questions
- the cipher suites in the RFC dont include a NULL cipher is the NULL cipher e.g. there's no DHE_RSA_NULL_SHA. Openssl headers e.g. tls1.h does provide for a lot of cipher suites with NULL ciphers which dont figure in the RFC. However, they dont get built into the configuration on my platform which may indicate this is not a normal things to use. Similarly tools like socat dont seem to negotiate cipher suites with null ciphers.. So I'm wondering if interoperability wise this kind of optimisation is thin ice even if the eco-system is partly controlled.
- There's a load of stuff that doesnt get defined in the RFC, like what the possible values are for SecurityParameters.mac_algorithm, validating the MAC on incoming message. People implementing TLS have a more detailed standard or am i missing something ?