While 3DES as a cipher suite has been available for quite some time, the drumbeat around its discontinuation has been a little lackluster. NIST issued its original deprecation guidance in 2017 in draft format, and as of 01 January 2024 its only use is for known applications in legacy format, for decryption only. Which means anyone who wants to start a new TLS connection (and who amongst us doesn’t?) needs to update their z/VM TLS configuration in order to move back into compliance.

How, I hear you asking? You’ve come to the right place.

z/VM TLS Settings

If you're already an expert on z/VM TLS, you can skip this section

The z/VM TLS server has a lot of knobs and buttons for fine-tuning security policy, but they do take some time to learn. Here are the options you can use for general modification and adjustment.

  1. MODE – this parameter will allow for auto-configuration to meet certain standards (either FIPS 140-2 or NIST SP 800-131a).
  2. PROTOCOL – this parameter is for TLS version specification. 1.1 and 1.2 are enabled by default. At a cipher level, this won’t impact 3DES, but it will disable older ciphers (e.g. the DES-based ones) for TLS 1.2.
  3. EXEMPT/ENABLE – these keywords allow you to establish a security baseline by turning off/on cipher suites which do not meet local security requirements. While EXEMPT allows for “by strength” rather than “by name,” the strengths are determined by IBM, and are not necessarily configurable.

Specific Statements Needed to Remove all 3DES Ciphers

“Cut to the chase,” I hear you saying! Very well. If you want to remove 3DES from your list of available cipher suites, insert the following block of text into the :Parms. section of your TLS Server’s configuration, in the DTCPARMS file:

EXEMPT 3DES_18_SHA
EXEMPT DH_DSS_3DES
EXEMPT DH_RSA_3DES
EXEMPT DHE_DSS_3DES
EXEMPT DHE_RSA_3DES
EXEMPT ECDH_ECDSA_3DES_EDE_SHA
EXEMPT ECDH_RSA_3DES_EDE_SHA
EXEMPT ECDHE_ECDSA_3DES_EDE_SHA
EXEMPT ECDHE_RSA_3DES_EDE_SHA

Some of these will be disabled by default for anyone without a previously modified DTCPARMS; however, it’s not a bad idea to disallow explicitly items you’d prefer not to have crop up – while IBM won’t change its mind and start allowing ciphers it previously disabled (without a service update), updating your configuration files is the fastest way to validate that all appropriate local changes have been made.

Remember that you’ll need to restart your TLS servers to pick up the new configuration. This can be accomplished via general re-IPL (if you’re feeling frisky) or via SSLADMIN if you’d like the more official approach:

SSLADMIN RESTART (SSLserver ALL

Follow-On Thoughts

It’s acknowledged that this is a cumbersome process, inasmuch as one has to exempt on a per-cipher basis. While there is some degree of mitigation through items like Exempt-by-Strength, that feature is mutually exclusive to per-cipher exemptions, and it won’t help in cases where sudden changes are required.

3DES is not a sudden change, we’ve known about this for literal years! However, it’s understood that the exercise of crypto inventory is a non-trivial one, and legacy applications sometime demand functionality we’d just as soon leave behind. All security decisions are, in the end, business decisions – but if the above helps you with your local network security scanning automation, then it was time well spent to type up.