ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Relative overhead of ciphers on MQ channels z/os

Post new topic  Reply to topic
 Relative overhead of ciphers on MQ channels z/os « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Wed Oct 07, 2020 5:53 am    Post subject: Relative overhead of ciphers on MQ channels z/os Reply with quote

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
View user's profile Send private message
gbaddeley
PostPosted: Wed Oct 07, 2020 2:20 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
zpat
PostPosted: Wed Oct 07, 2020 10:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Thu Oct 08, 2020 5:07 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Oct 08, 2020 10:05 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
zpat
PostPosted: Sun Oct 11, 2020 7:05 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Sun Oct 11, 2020 8:01 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Oct 11, 2020 1:07 pm    Post subject: Re: Relative overhead of ciphers on MQ channels z/os Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
gbaddeley
PostPosted: Mon Oct 12, 2020 2:35 pm    Post subject: Re: Relative overhead of ciphers on MQ channels z/os Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
bruce2359
PostPosted: Mon Oct 12, 2020 6:02 pm    Post subject: Re: Relative overhead of ciphers on MQ channels z/os Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Relative overhead of ciphers on MQ channels z/os
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.