What Radoslaw said re TLS versions. But you mostly probably don't need to worry
too much about it, unless you're writing an application that will manage the
actual connection. In that case, the application has to tell System SSL (the
z/OS TLS stack) what it wants/is willing to use. This is sort of sad in that in
most cases you just want it to use the latest and greatest: if it's talking to
a peer that can do TLSv1.3, hey, do that; if 1.4 comes along, use that! But
that's how it mostly works.
OTOH if you use OpenSSL under the covers, *it's* smart enough to do the
negotiation to the highest level that it knows about, so an upgrade to TLSv1.4
(if/when it arrives) would be a matter of upgrading OpenSSL, not changing your
code.
But it's still not clear here what you're trying to do. If it's JUST protecting
the data in transit, then TLS is mostly good enough. I say "mostly" because
with quantum computing maybe eventually possibly conceivably becoming real, a
HNDL ("Harvest Now, Decrypt Later") attack becomes a concern. This is where an
attacker records the TLS transaction and later, if Post-Quantum Cryptography is
ever real, uses that to break it and extract the data. It also means that the
entry and exit points of the TLS tunnel are rich targets.
The fact that you mention AES makes me think that HNDL is on your (or your
customer's) radar, and they plan to protect the data before it enters the TLS
pipe and decrypt it at the other end. That's wise: even though it's unclear
that quantum will ever be real, if it did, this would make HNDL useless against
that data. Well, useless assuming you have a decent way to exchange keys.
That's always the challenge! Also, if you do this, those TLS entry/exit points
lose all value as targets.
Eric Rossman's comments re quantum are of course trenchant. Once Post-Quantum
Cryptography TLS algorithms are available (at both ends!) HNDL presumably
becomes moot. OTOH, more layers is better, so AESing the data outside the
tunnel would still be a good idea. Choose your AES modes carefully--there's
probably no reason to use anything other than GCM for what you're talking
about, though, again, the use case isn't 100% clear.
Can you elaborate on the real requirements some more?
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Steve Estle
Sent: Friday, October 3, 2025 2:01 PM
To: [email protected]
Subject: Re: ZSeries Crypto Cards - Decision Table?
Thanks all, what have you found to be the best sources of information for such
architecting / reference / decisions / howto given we are not interested in
encrypting "data at rest" (at least not now) and only interested in encryption
over Comm Srvr controlled links. Is it strictly Comm Server 3.1 Doc or do you
have other documentation that you feel is essential?
You hit upon a key point on the asymmetric vs. symmetric key exchanges - not
sure I understand why you say "go with TLS 1.3 - no reason not to"... My
understanding is some crypto algorithms are no longer valid in TLS 1.3 (in
other words not a superset of TLS 1.2) but open to being educated on that?
Thanks,
Steve Estle
CDW
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
