| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Relative overhead of ciphers on MQ channels z/os |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Wed Oct 07, 2020 5:53 am Post subject: Relative overhead of ciphers on MQ channels z/os |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We have a MQ sender/receiver channel pair to another QM - one end is z/OS MQ v9.0 and the other end is z/OS MQ v9.1
It's high volume (hundreds per second) and currently secured with the TLS 1.2 cipher TLS_RSA_WITH_AES_256_CBC_SHA256
The average request message on the sender channel is small (about 2kb) and the average response message is medium size (about 32kb).
Now, if we changed the cipher to ECDHE_RSA_AES_128_GCM_SHA256 - what would be the likely effect on CHIN CPU usage on the z/OS v9.0 side?
Support pac MP16 doesn't really provide any info on this newer GCM cipher.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Wed Oct 07, 2020 2:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
AES 128 GCM is faster than AES 256 CB, so CPU might go down a bit. Does z/OS use hardware for AES crypto?
The ECDHE RSA and SHA256 parts of the spec are only used for initialization. Once the session private keys are established at each end, the AES part is free running on the data payload.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 07, 2020 10:41 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks for that. Yes I assume that z/OS 2.3 on a z/14 will use the cryptographic processor.
In fact the CHIN needs RACF read access to a resource in the CSFSERV class for the GCM cipher to work at all so it must use it.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Oct 08, 2020 5:07 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
From what I have read, CBC (Cipher Block Chaining) has to be performed sequentially, while GCM (Galois Counter Mode) can be performed in parallel. This should lead to better performance with GCM, but I would of course confirm that with testing, consulting your security experts, etc.
I would also recommend double checking with IBM if this blurb below for GCM under TLS 1.2 does apply to z/OS. This blurb used to be about a NIST restriction of 2^32 TLS records being sent under TLS 1.2, and then was changed to another GCM restriction that was raised in the TLS 1.3 specification and has to do with 2^24.5 TLS records being sent under TLS 1.2. If z/OS is not resetting the symmetric keys for GCM before 2^24.5 TLS records are sent, then I would think this GCM restriction DOES apply to z/OS for TLS 1.2.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q014260_.htm
| Quote: |
Following a recommendation by GSKit, TLS 1.2 GCM CipherSpecs have a restriction which means that after 2ˆ24.5 TLS records are sent, using the same session key, the connection is terminated with message AMQ9288.
To prevent this error from happening: avoid using TLS 1.2 GCM Ciphers, enable secret key reset, or start your IBM MQ queue manager or client with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set.
This restriction does not apply to IBM MQ for z/OS®. |
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 08, 2020 10:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moving this to mainframe forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Oct 11, 2020 7:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
That restriction does not apply to z/OS MQ, already checked with the support center.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Oct 11, 2020 8:01 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
You should see evidence then of key resets when more than 2^24.5 TLS records are sent at TLS 1.2 on Z with a GCM cipher. I see that happening with TLS 1.3 on distributed with GCM ciphers. Something worth validating.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 11, 2020 1:07 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| It's high volume (hundreds per second) ... |
Not to quibble, but on a midrange platform hundreds per second might be high message volume. On z/OS monoplex, thousands per second might be high volume. If parallel sysplex, tens of thousands might be considered high volume.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Oct 12, 2020 2:35 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| zpat wrote: |
| It's high volume (hundreds per second) ... |
Not to quibble, but on a midrange platform hundreds per second might be high message volume. On z/OS monoplex, thousands per second might be high volume. If parallel sysplex, tens of thousands might be considered high volume. |
It might be.... An appropriately specced midrange server can do amazing things. Every platform has its place.
For planning purposes, anything over 50-100 messages a second can be considered high volume, where multiple factors outside of MQ have a bearing on achieving performance.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 12, 2020 6:02 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| gbaddeley wrote: |
| bruce2359 wrote: |
| zpat wrote: |
| It's high volume (hundreds per second) ... |
Not to quibble, but on a midrange platform hundreds per second might be high message volume. On z/OS monoplex, thousands per second might be high volume. If parallel sysplex, tens of thousands might be considered high volume. |
It might be.... An appropriately specced midrange server can do amazing things. Every platform has its place.
For planning purposes, anything over 50-100 messages a second can be considered high volume, where multiple factors outside of MQ have a bearing on achieving performance. |
Of course. I deliberately excluded non-MQ, components - like database accesses.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
