|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
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 |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
gbaddeley |
Posted: Wed Oct 07, 2020 2:20 pm Post subject: |
|
|
![](images/avatars/gallery/Star Wars/movie_star_wars_yoda.gif) Jedi Knight
Joined: 25 Mar 2003 Posts: 2501 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
zpat |
Posted: Wed Oct 07, 2020 10:41 pm Post subject: |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
tczielke |
Posted: Thu Oct 08, 2020 5:07 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 939 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Thu Oct 08, 2020 10:05 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9407 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
zpat |
Posted: Sun Oct 11, 2020 7:05 am Post subject: |
|
|
![](images/avatars/200698233754e3c3649f6d0.jpg) Jedi Council
Joined: 19 May 2001 Posts: 5849 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
tczielke |
Posted: Sun Oct 11, 2020 8:01 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 939 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Sun Oct 11, 2020 1:07 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9407 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
gbaddeley |
Posted: Mon Oct 12, 2020 2:35 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
![](images/avatars/gallery/Star Wars/movie_star_wars_yoda.gif) Jedi Knight
Joined: 25 Mar 2003 Posts: 2501 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Mon Oct 12, 2020 6:02 pm Post subject: Re: Relative overhead of ciphers on MQ channels z/os |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9407 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 |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|
|
![Reply to topic](templates/DAJ_Glass/images/lang_english/reply.gif) |
|
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
|
|
|
|