3

I wonder about the benefits of the following ciphers:

  • TLS_ECDHE_PSK_WITH_NULL_SHA256
  • TLS_ECDHE_ECDSA_WITH_NULL_SHA

Why should I go for perfect forward secrecy if I don't want to encrypt in the first place? I just want to go for Authenticity/Integrity..

Why are those ciphers even listed in the registry? Is it for the sake of completeness or am I overlooking important use cases?

  • I think I can construct a case where that's useful: developer-testing an application that chatters over TLS. Say you want to view / debug the network traffic but can't / don't want to give wireshark the server private key. – Mike Ounsworth Jul 12 '17 at 14:08
1

The NULL encryption was introduced after RFC 4785 which was introduced support for different import restrictions among other things:

Quoting the RFC:

There are also cases when confidentiality is not permitted - e.g., for implementations that must meet import restrictions in some countries. Even though no encryption is used, these ciphersuites support authentication of the client and server to each other, and message integrity.

Reference: https://tools.ietf.org/html/rfc4785

The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate.

  • Sorry, I was not clear enough: why is there is a cipher suite for exchanging keys with ephemeral DH, if no Encryption is desired? (EC)DHE.xxx.WITH_NULL – Gannic Jul 4 '17 at 14:28
  • My guess is that this key exchange is done for generating the keys for authentication – Limit Jul 6 '17 at 13:15
1

As far as I can tell, they exist for completeness only. The PSK cipher suites (and there are several of them) first defined in RFC 5489 without meaningful comment, only:

The following cipher suite matches the cipher suites defined in Section 3.1, except that we define a suite with NULL encryption.

and similar.

The ECDHE_ECDSA cipher suite definition is even less verbose, with no comment at all, but it's clear from looking at the definition in RFC 4492 that the situation is the same. The list of cipher suites being defined is simple a repeating list enumerating each combination of supported key exchange, authentication, and encryption algorithm, including NULL.

  • So it' really is just there for completeness? I could see that being useful for developers trying to test / wireshark their TLS connections, but it's likely that there's no possible reason to use it in production? – Mike Ounsworth Jul 12 '17 at 14:05
  • @MikeOunsworth I would agree that is probably the case. I certainly haven't been able to find a compelling reason for using them outside of dev/testing documented anywhere. – Xander Jul 12 '17 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.