MQ

Recently I wrote a blog discussing the impact of the key-size in a certificate when using Advanced Message Security (AMS), which showed demonstrable impact to the achieved transaction rates, particularly with smaller messages.

It will come as no surprise that the certificate key-size used by your MQ for z/OS queue managers for use with TLS-protected MQ channels will also result in some performance impact.

The “Capacity Planning and Tuning for IBM MQ for z/OS” report (MP16) does discuss the performance of starting MQ channels in the Channel Initiator section titled “Channel start/stop rates and costs”.

Unlike the AMS performance measurements, the data reported in the section in MP16 all relied on the RACF certificate using the default key-size of 2048 bits (for RSA) and 192 bits for NISTECC. These defaults were last changed with the release of z/OS 2.2 (2015).

In that section, we discussed the performance when starting TLS-protected MQ channels on IBM z16 (3931) with cryptographic assistance provided by Crypto Express 8S Coprocessors.

Whilst the system is configured with Cryptographic Accelerators, the usage of the accelerator when starting TLS -protected channels is insignificant.

The additional section “SSL and TLS” discusses when an MQ workload will incur costs relating to "encryption", from which I have included extracts below for the sake of clarity:

• Starting and stopping of the channel.
• Re-negotiate the secret key – which depends on the value of SSLRKEYC and the volume of data flowing over the channel. TLS 1.3 ciphers have key re-negotiation as part of the protocol and should use SSLRKEYC(0) for best performance.
• Encryption and decryption of data. Certificate key-size is not a factor in the encryption or decryption of this data. 

As many users of TLS-protected channels implement large values for SSLRKEYC which results in relatively infrequent secret key re-negotiations, this blog will focus on the area with most impact from certificate key-size, i.e. channel start.

You may have read in the AMS blog that using a larger key-size with the certificate does not typically have a significant impact on the cost of the measurement. This is also true with the starting of TLS-protected channels.

However, the key-size using in the certificate does have a marked impact on the rate at which the MQ channels may be started.

It is worth noting that the performance observed in the following measurements with a key-size of 2048 are, and should be, very similar to that documented in MP16. There is some small variation due to the simplicity of the workload.

Measurement Environment

For the purposes of this blog, the environment used to measure the performance was:

• 2 z/OS 2.5 LPARs, each configured with 3 dedicated CPUs running on a single IBM z16 (3931-A01) with a 10Gb TCPIP link between the 2 LPARs.
• Each LPAR has 2 Crypto Express8S adaptors configured as coprocessors.
• Additionally, there is a single Crypto Express8S adaptor configured as an accelerator, shared across the sysplex.
• 2 MQ queue managers running at MQ for z/OS v930.

What are we measuring?

For the purposes of this blog, I have recreated the measurements in MP16 for both TLS 1.2 and TLS 1.3 ciphers, primarily using the RSA key-sizes of 1024, 2048 and 4096 bits, and where appropriate NISTECC key-sizes of 192, 224 and 521 bits.

Note that as per the RACDCERT GENCERT documentation:

• NISTECC key-size 192 is equivalent to RSA key-size 1024.
• NISTECC key-size 224 is equivalent to RSA key-size 2048.
• NISTECC key-size 521 is equivalent to RSA key-size 15360.
  • In this case, the NISTECC 521 bits and RSA 4096-bits are the largest supported key sizes on z/OS. There is no equivalent NISTECC key-size for RSA 4096-bits.

Whilst the default NISTECC key-size is 192, this is equivalent to less than the RSA default of 2048. As such, this blog will refer to the key-sizes using the following labels: medium, high, and very high to indicate their strength, as below:

The measurements define 4000 sender and 4000 receiver type channels on each queue manager.

The measurement then runs a batch CSQUTIL job to start 4000 sender channels on 1 queue manager, using RMF data to determine the cost and SDSF log data to determine the start rate.

TLS 1.2 ciphers

The following charts compare the performance of the TLS 1.2 ciphers supported by the z/OS queue manager.

They show the rate at which our test was able to start the channels over a low-latency network, which reduces the impact of network time on any negotiation.

A second chart shows the cost incurred by the channel initiator address space, averaged over the 4000 channels being started.

Start Rate:

In terms of the certificate key size affecting the TLS-protected channel start time, there is a notable impact particularly moving from high to very high strength key strengths.

Note: I have calculated the channel start time by dividing 1 million (CPU microseconds) by the channel start rate data from the above chart. Using this calculated channel start time, I have then compared the 3 strengths of key-size.

The impact to channel start time can be grouped by cipher prefixes as per the table below:

In a configuration where network latency is larger, due to the 2 queue managers being further apart, the impact to starting the channels may be less than we observed.

Cost of starting MQ channel:

In terms of impact to TLS 1.2-protected channel start costs with increasing certificate key-sizes, there is no significant impact when moving from medium to high strength keys.

Channel start costs when moving from high to very high strength keys can be grouped as follows:

• TLS_RSA prefixed ciphers increased by up to 7%.
• TLS_ECDHE_ECDSA prefixed ciphers (NISTECC) increased by 1.35%.
• TLS_ECDHE_RSA prefixed ciphers increased by up to 3%.

TLS 1.3 ciphers

TLS 1.3 ciphers are slightly different as “System SSL only supports RSA key sizes 2048 bits and larger and ECC keys 256 bits and larger when attempting to do TLS V1. 3 handshakes”.

Despite the MQ-supported TLS 1.3 ciphers supporting only RSA keys, I have continued to use “high” for key-size of 2048 bits and “very high” for key-size of 4096 bits.

Start Rate:

In terms of the certificate key size affecting the TLS-protected channel start rate, the channels take approximately twice as long to start when using the very high strength key-size compared to the high strength key-size.

Cost of starting MQ channel:

For the TLS 1.3 ciphers, we found using a key-size of 4096 bits cost between 5 and 8% more than using a certificate with 2048 bits.

Load on cryptographic hardware:

The load on the cryptographic hardware at channel start or at the time the secret key is re-negotiated is not significant, provided these do not occur with high frequency.

Table showing percent utilized of a single Crypto Express 8S coprocessor when starting 4000 sender-type channels:

Whilst the cryptographic hardware usage relating to MQ channel start would not typically be as high as this table suggests since we are starting 4000 channels, it does suggest that moving from high to very high key strengths might intermittently increase the load by a factor of 5, and as such it is prudent to ensure that there is sufficient capacity available prior to increasing the certificate key-size.

Secret Key Re-negotiation

Earlier in this blog, I mentioned that many users of MQ TLS-protected channels specify large values, or indeed a value of 0, for SSLRKEYC and therefore may not see much impact from secret key re-negotiation.

However, it is worth drawing attention to the potential impact, particularly when frequent key re-negotiation occurs.

The following chart shows the impact on the transaction rate, using a request-reply model with 32KB non-persistent messages, where SSLRKEYC is set to 0 or 1MB and the key-size is increased from 2048 to 4096 bits.

The configuration uses the same SSLRKEYC on both inbound and outbound channels, which means that a 1 secret key negotiation is occurring approximately every 16 transactions.

Notes on chart:

• When SSLRKEYC is set to 0, the transaction rate achieved is 6676 per second and this is regardless of the certificate’s key-size.
• When using an SSLRKEYC of 1MB and a key-size of 2048 bits, the transaction rate drops to 1830 per second, a drop of 72%, i.e. a significant impact.
• When the key-size is doubled to 4096 bits with this frequent key re-negotiation, the transaction rate decreases to 1035 per second, a decrease of 43% over the 2048-bit measurement.

It is worth noting that when using SSLRKEYC(1MB), the transaction cost is virtually identical, regardless of the key-size specified in the certificate.

In terms of Cryptographic hardware usage, we can calculate each secret key re-negotiation as using:

Summary

Given the time since key-sizes classed as high strength have been z/OS’s default size (NISTECC excluded), it is likely that most interest in the impact of key-size will come from moving from high to very-high strength keys.

As the blog demonstrates, moving from high to very-high strength keys will have minimal impact on the cost of IBM MQ’s interaction with the cryptographic hardware, but there can be a significant impact to the time taken to complete that interaction as well as the load on the cryptographic hardware adaptor.

In our measurements, the rate at which MQ channels were started when using TLS 1.3 ciphers halved when using very-high strength keys compared to high strength keys.

TLS 1.2 ciphers generally saw less of an impact from the higher strength keys – although TLS_RSA prefixed ciphers were particularly impacted such that rates dropped by more than half.

It is worth re-iterating that in a configuration where network latency is larger due to the 2 queue managers being further apart, the impact to starting the channels with larger key-sizes in the certificate may be less than we observed on our very low-latency network.

Ultimately performance is not, and should not be, the driving factor behind the size of the key used in the certificate but hopefully this blog provides some indication as to what impact you might see when migrating to larger key-sizes.