| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| CipherSpec and CipherSuite Terminology in IBM MQ Manual |
« View previous topic :: View next topic » |
| Author |
Message
|
| tczielke |
 Posted: Thu Feb 14, 2019 2:18 pm Post subject: CipherSpec and CipherSuite Terminology in IBM MQ Manual |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If you are like me, you have been a little confused in how the IBM MQ manual talks about both a CipherSpec and a CipherSuite. When you read the IBM MQ documentation, it seems to suggest that CipherSpec is an IBM MQ terminology and CipherSuite is Java terminology, both pointing to a set of encryption algorithms (e.g. TLS_RSA_WITH_AES_128_CBC_SHA256) to be used for a TLS session.
I have been doing a lot of research in the IETF TLS documents (IETF is the group that supports TLS), and I have come to the conclusion that the IBM MQ manual is incorrectly using an older SSL v2 term when they say CipherSpec, and what they really should be using is the term CipherSuite.
In the IETF SSL v3 and TLS RFC documents, there is a defined term called CipherSpec. It represents the symmetric encryption/MAC that was negotiated for the TLS session. An example of a CipherSpec would be the combination of AES_128_CBC and SHA256 where AES_128_CBC is being used for the symmetric encryption of the record data and SHA256 is the MAC hash algorithm to authenticate the record data.
A CipherSuite defines all the different types of encryption (not just symmetric/MAC) that are used in a TLS session. For example, TLS_RSA_WITH_AES_128_CBC_SHA256 is a CipherSuite which describes the asymmetric encryption (RSA), symmetric encryption (AES_128_CBC) and MAC hash algorithm (SHA256) that will be used in the TLS session.
Therefore, I feel it is incorrect for this following IBM MQ manual document to call TLS_RSA_WITH_AES_128_CBC_SHA256 a CipherSpec. The CipherSpec portion would be AES_128_CBC and SHA256, and even using the term CipherSpec is somewhat antiquated. I believe it was more commonly used at SSL v2.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q014260_.htm
If anyone disagrees with my comments/analysis, please let me know.
If I don’t hear any disagreements, I will forward this onto the IBM MQ manual team to request that they change the incorrect CipherSpec terminology to CipherSuite.
NOTE: Here is where the CipherSpec is defined in SSL 3.0 RFC 6101 as the negotiated symmetric encryption/MAC for the TLS session:
SSL 3.0 -> https://tools.ietf.org/html/rfc6101#page-47
| Quote: |
A.7. The CipherSpec
A cipher suite identifies a CipherSpec. These structures are part of
the SSL session state. The CipherSpec includes:
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { null, rc4, rc2, des, 3des, des40, fortezza }
BulkCipherAlgorithm;
enum { null, md5, sha } MACAlgorithm;
struct {
BulkCipherAlgorithm bulk_cipher_algorithm;
MACAlgorithm mac_algorithm;
CipherType cipher_type;
IsExportable is_exportable
uint8 hash_size;
uint8 key_material;
uint8 IV_size;
} CipherSpec;
|
_________________
Working with MQ since 2010. |
|
| Back to top |
|
 |
| hughson |
| Posted: Fri Feb 15, 2019 12:19 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
Back in WebSphere MQ V5.3, when SSL was added to MQ, the strings in the SSLCIPH field were CipherSpecs. They did not include the key exchange algorithm because RSA was assumed. Lack of foresight on our part no doubt.
Think of the old SSLCIPH strings such as TRIPLE_DES_SHA_US or RC_MD5_US.
Things have moved on now, and I would say your analysis is right. They are now CipherSuites.
The MQSC Keyword SSLCIPH is (apart from being named SSL... - again lack of foresight, who knew they would change the name of the darned thing!) at least short enough (thanks to MQSC 8 char limit) to represent either CipherSpec or CipherSuite.
The PCF constant, for the same field MQCACH_SSL_CIPHER_SPEC (value 3544) could be duplicated and another constant made with the same value called MQCACH_SSL_CIPHER_SUITE except that one already exists with that name and value 3569, I think for AMQP channels.
So to completely change over, I would say it is not just a doc exercise, and suggest you [also] raise an RFE.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 15, 2019 5:47 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Thank you for that helpful information! I went with a e-mail to the IBM Knowledge Center support to ask them to correct the terminology to use CipherSuite instead of CipherSpec (where appropriate).
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 15, 2019 12:31 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 15, 2019 1:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 15, 2019 1:57 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I have seen all three of those links and I would say they are all in error when they reference any TLS CipherSuite as a CipherSpec. I have raised this to the IBM MQ Knowledge Center to get this corrected.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 15, 2019 2:01 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| What did you suggest they alter on the page I linked to? |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 15, 2019 2:11 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I think it is incorrect and misleading to use the term CipherSpec, unless you are really talking about a CipherSpec as defined in the IETF TLS documentation. The general comment was for IBM to change their common use of CipherSpec to be CipherSuite. So I would expect that page to change CipherSpec to CipherSuite. It is linking off to pages called "Enabling CipherSpecs" which are clearly talking about CipherSuites and not CipherSpecs. However, it does sound like at some points in that page, it is talking about a true CipherSpec.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 15, 2019 4:25 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
I suspect you are more of an expert, having done plenty of recent research.
But I think MQ has been using these terms consistently, at least, for many many years.
I remember in the early days of MQ 5.3 getting some training on the (then) newly added functionality to allow SSL over MQ channels.
The term cipherspec was in use back then, and consistently throughout all that time.
Are you saying MQ always used the term incorrectly?
IMHO it seems doubtful to me that a change can now be made (even assuming you are right) without confusing everyone thoroughly. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 15, 2019 7:20 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I would say for the IBM MQ queue manager channel SSLCIPH side, IBM has been consistently calling a CipherSpec a CipherSpec and a CipherSuite a CipherSpec. The latter is incorrect, and should be corrected in the doc and wherever else is appropriate in the product. If they want to make the change is up to them, but you look kind of foolish to keep using the wrong terminology once you know it is wrong, in my opinion.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 15, 2019 8:04 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
One other note. IBM hopefully has this on their radar, but please use the IETF TLS CipherSuite names for TLS 1.3 for IBM MQ and the IBM JSSE:
TLS 1.3 RFC -> https://tools.ietf.org/html/rfc8446
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
This will prevent the CipherSuite naming mismatch we have at TLS 1.2 between IBM MQ/IBM JSSE and the Oracle JSSE/IETF CipherSuite naming standard.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Feb 22, 2019 7:24 pm Post subject: Re: CipherSpec and CipherSuite Terminology in IBM MQ Manual |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Developerworks has a few blog posts, here and here, to provide some additional context. The TLS docs haven't always been that clear either, about differentiating between a "CipherSpec" and a "CipherSuite". TLS v1.2 is still currently using "CipherSpec", so the term is not that antiquated, (although it has been partly replaced with "SecurityParameters"):
| Quote: |
7. The TLS Handshaking Protocols
cipher spec: Specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines cryptographic attributes such as the mac_length. (See Appendix A.6 [The Security Parameters] for formal definition.)
A.5. The Cipher Suite
A cipher suite defines a cipher specification supported in TLS Version 1.2. |
Is "cipher specification" supposed to be the same as "cipher spec" here? Is a cipher suite supposed to define a unique cipher spec, or could two different cipher suites, (such as TLS_RSA_WITH_AES_128_CBC_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256), define the same cipher spec, (or could the same cipher suite match two different cipher specs)?
| tczielke wrote: |
| A CipherSuite defines all the different types of encryption (not just symmetric/MAC) that are used in a TLS session. |
That's no longer true though, as of TLS v1.3; a CipherSuite specifies just symmetric/MAC encryption, like the CipherSpec used to do:
| Quote: |
1.2. Major Differences from TLS 1.2
The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC).
B.4. Cipher Suites
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3. |
But IBM MQ doesn't support TLS v1.3 yet, so how does that affect what should go into the IBM MQ docs?
| tczielke wrote: |
please use the IETF TLS CipherSuite names for TLS 1.3 for IBM MQ and the IBM JSSE:
| Code: |
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+ |
|
Does the two-byte Value uniquely identify the cipher suite, or does the Description? Are the descriptions a normative part of the standard? Because IETF has changed them at least once before, (for example, from "SSL_*" to "TLS_*", between SSL v3.0 and TLS v1.0). That could explain why Oracle seems to have named their JSSE Cipher Suites better than IBM did; they just waited until after the descriptions changed to implement most of them.
| tczielke wrote: |
| This will prevent the CipherSuite naming mismatch we have at TLS 1.2 between IBM MQ/IBM JSSE and the Oracle JSSE/IETF CipherSuite naming standard. |
At least until IETF decides to change the descriptions again, in some future version of whatever replaces TLS. |
|
| Back to top |
|
|
| tczielke |
| Posted: Fri Feb 22, 2019 8:16 pm Post subject: Re: CipherSpec and CipherSuite Terminology in IBM MQ Manual |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| rekarm01 wrote: |
Developerworks has a few blog posts, here and here, to provide some additional context. The TLS docs haven't always been that clear either, about differentiating between a "CipherSpec" and a "CipherSuite". TLS v1.2 is still currently using "CipherSpec", so the term is not that antiquated, (although it has been partly replaced with "SecurityParameters"):
| Quote: |
7. The TLS Handshaking Protocols
cipher spec: Specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines cryptographic attributes such as the mac_length. (See Appendix A.6 [The Security Parameters] for formal definition.)
A.5. The Cipher Suite
A cipher suite defines a cipher specification supported in TLS Version 1.2. |
Is "cipher specification" supposed to be the same as "cipher spec" here? Is a cipher suite supposed to define a unique cipher spec, or could two different cipher suites, (such as TLS_RSA_WITH_AES_128_CBC_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256), define the same cipher spec, (or could the same cipher suite match two different cipher specs)?
| tczielke wrote: |
| A CipherSuite defines all the different types of encryption (not just symmetric/MAC) that are used in a TLS session. |
That's no longer true though, as of TLS v1.3; a CipherSuite specifies just symmetric/MAC encryption, like the CipherSpec used to do:
| Quote: |
1.2. Major Differences from TLS 1.2
The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC).
B.4. Cipher Suites
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3. |
But IBM MQ doesn't support TLS v1.3 yet, so how does that affect what should go into the IBM MQ docs?
| tczielke wrote: |
please use the IETF TLS CipherSuite names for TLS 1.3 for IBM MQ and the IBM JSSE:
| Code: |
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+ |
|
Does the two-byte Value uniquely identify the cipher suite, or does the Description? Are the descriptions a normative part of the standard? Because IETF has changed them at least once before, (for example, from "SSL_*" to "TLS_*", between SSL v3.0 and TLS v1.0). That could explain why Oracle seems to have named their JSSE Cipher Suites better than IBM did; they just waited until after the descriptions changed to implement most of them.
| tczielke wrote: |
| This will prevent the CipherSuite naming mismatch we have at TLS 1.2 between IBM MQ/IBM JSSE and the Oracle JSSE/IETF CipherSuite naming standard. |
At least until IETF decides to change the descriptions again, in some future version of whatever replaces TLS. |
It seems to me that IBM MQ just didn't change their TLS documentation correctly when the IETF TLS documentation started using CipherSuite in place of CipherSpec, but that is an assumption on my part. I personally found the IBM MQ TLS use of CipherSpec very confusing until I read the TLS 1.2 RFC specification in its entirety and had an aha moment on what probably happened. But again I do admit, this is an assumption on my part.
This comment you made here is incorrect:
| Quote: |
| That's no longer true though, as of TLS v1.3; a CipherSuite specifies just symmetric/MAC encryption, like the CipherSpec used to do: |
A TLS 1.3 CipherSuite is not specifying the symmetric/MAC encryption used to encrypt and authenticate the record like the CipherSpec at SSL v2. The TLS 1.3 CipherSuite is now specifying TLS_AEAD_HASH where AEAD is the Authenticated Encryption with Associated Data (which is both a combination of symmetric encryption and MAC) alogrithm used to both encrypt and authenticate the record, and the HASH part of the CipherSuite is the hash algorithm used for HKDF.
In regards to IBM deviating from the CipherSuite description name, I would think any TLS implementor would want to follow the documented CipherSuite description names. Especially, if you are going to require the admin/programmer to externally specify it for your MQ TLS application to work like IBM MQ does (e.g. MQ channel SSLCIPH).
My main point in making those comments/pleas about TLS 1.3 is that IBM MQ has not released TLS 1.3 yet, at least as far as I know. They still have an opportunity to get consistent with the IETF documented CipherSuite names at TLS 1.3, and avoid some of the pitfalls we are still dealing with at TLS 1.2 where IBM (MQ and JSSE) deviated from the IETF CipherSuite names.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Feb 26, 2019 7:02 am Post subject: Re: CipherSpec and CipherSuite Terminology in IBM MQ Manual |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| tczielke wrote: |
| It seems to me that IBM MQ just didn't change their TLS documentation correctly when the IETF TLS documentation started using CipherSuite in place of CipherSpec ... |
Certainly, anything that IBM MQ can do to make its own documentation clearer and less confusing would help. But the IETF RFCs did not start using "CipherSuite" in place of "CipherSpec"; they continued to define and use both terms separately, up until TLS 1.3.
| tczielke wrote: |
This comment you made here is incorrect:
| Quote: |
| That's no longer true though, as of TLS 1.3; a CipherSuite specifies just symmetric/MAC encryption, like the CipherSpec used to do: |
|
The TLS 1.3 CipherSuite no longer "defines all the different types of encryption that are used in a TLS session", because "TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers ...".
| tczielke wrote: |
| In regards to IBM deviating from the CipherSuite description name, ... |
But did they? It looks more like the IBM JSSE provider followed the Netscape cipher suite description names, and then later, IETF deviated from Netscape, and then later, IBM added new cipher suite description names to follow IETF:
| Quote: |
| In the following list, the string "SSL" is interchangeable with "TLS" and vice versa. For example, where SSL_RSA_WITH_AES_128_CBC_SHA is specified, TLS_RSA_WITH_AES_128_CBC_SHA also applies. |
Regardless of the history, it looks like IBM supports the TLS 1.2 names now. Maybe that's another area where IBM needs to update the MQ documentation? Oracle, on the other hand, still has a few "SSL_*" cipher suites enabled, that don't follow the IETF convention. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Feb 26, 2019 11:56 am Post subject: Re: CipherSpec and CipherSuite Terminology in IBM MQ Manual |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| rekarm01 wrote: |
| tczielke wrote: |
| It seems to me that IBM MQ just didn't change their TLS documentation correctly when the IETF TLS documentation started using CipherSuite in place of CipherSpec ... |
Certainly, anything that IBM MQ can do to make its own documentation clearer and less confusing would help. But the IETF RFCs did not start using "CipherSuite" in place of "CipherSpec"; they continued to define and use both terms separately, up until TLS 1.3.
| tczielke wrote: |
This comment you made here is incorrect:
| Quote: |
| That's no longer true though, as of TLS 1.3; a CipherSuite specifies just symmetric/MAC encryption, like the CipherSpec used to do: |
|
The TLS 1.3 CipherSuite no longer "defines all the different types of encryption that are used in a TLS session", because "TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers ...".
| tczielke wrote: |
| In regards to IBM deviating from the CipherSuite description name, ... |
But did they? It looks more like the IBM JSSE provider followed the Netscape cipher suite description names, and then later, IETF deviated from Netscape, and then later, IBM added new cipher suite description names to follow IETF:
| Quote: |
| In the following list, the string "SSL" is interchangeable with "TLS" and vice versa. For example, where SSL_RSA_WITH_AES_128_CBC_SHA is specified, TLS_RSA_WITH_AES_128_CBC_SHA also applies. |
Regardless of the history, it looks like IBM supports the TLS 1.2 names now. Maybe that's another area where IBM needs to update the MQ documentation? Oracle, on the other hand, still has a few "SSL_*" cipher suites enabled, that don't follow the IETF convention. |
I agree that I do need to be less definitive here. When I said "we are still dealing with at TLS 1.2 where IBM (MQ and JSSE) deviated from the IETF CipherSuite names." it would have been better to say "appears to have deviated". I don't have a good understanding of how IBM MQ, the IBM JSEE, and the Oracle JSSE evolved with the IETF TLS documentation. However, when I read the current IBM MQ manual usage of CipherSpec and see how the term is used in the IETF TLS documentation, the IBM MQ usage seems to be off. Anyway, I have forwarded the observeration to the IBM MQ Knowledge Center team and they can figure out if anything needs to be adjusted with IBM MQ's usage of the term CipherSpec.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
