GCM Restrictions, Birthday Problems, and IBM MQ

You may be wondering what GCM (Galois/Counter Mode), birthdays (actually the Birthday Problem/Paradox in probability theory), and IBM MQ have in common.  This blog post will lay the foundation on why I believe the 2^32 TLS record restriction for GCM that is documented in the “Enabling Cipherspecs” section of the IBM 9.1 manual does not apply to TLS (and subsequently IBM MQ TLS) for either mainframe or distributed.  Along the way we will touch on all three topics.

NIST GCM Restriction in the IBM MQ Manual

In the “Enabling Cipherspecs” section of the IBM MQ 9.1 manual, there is this note about GCM (Galois/Counter Mode) ciphersuites.

“Following a recommendation by NIST, GCM CipherSpecs have a restriction which means that after 2ˆ32 TLS records are sent, using the same session key, the connection is terminated with message AMQ9288.

To prevent this error from happening: avoid using GCM Ciphers, enable secret key reset, or start your IBM MQ queue manager with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set.

This restriction does not apply to IBM MQ for z/OS®.”

A TLS record is how encrypted data is sent between the TLS client and server.  So for distributed MQ, if you are using a GCM ciphersuite (e.g. ECDHE_ECDSA_AES_128_GCM_SHA256) and you send more than 2^32 TLS records for the same session key, the default behavior is to break the MQ connection with an AMQ9288 error.  Note too that for the mainframe it simply states “this restriction does not apply”.

Now the following gets very technical, but it is needed to explain the argument.  It also goes without saying that an IBM MQ customer should follow the explicit advice of the IBM MQ manual, until it is changed.  However, the IBM MQ manual does give you the option when using GCM ciphersuites for distributed “or start your IBM MQ queue manager with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set”.  An IBM MQ customer may feel more comfortable using this approach after reading this argument and having it validated by their appropriate security professionals and IBM MQ support.

NIST GCM Restriction

I believe the NIST GCM restriction that the MQ manual refers to comes from the 8.3 section “Constraints on the Number of Invocations” in the NIST SP 800-38D document “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC”. 

“8.3 Constraints on the Number of Invocations

The following requirement applies to all implementations that use either 1) the deterministic

construction with IVs whose length is not 96, or 2) the RBG-based construction, for IVs of any

length. In other words, unless an implementation only uses 96-bit IVs that are generated by the

deterministic construction:

The total number of invocations of the authenticated encryption function shall not exceed

2^32, including all IV lengths and all instances of the authenticated encryption function with

the given key.”

Now the above blurb is very technical, but here is a breakdown of what it is saying.  In order to perform a GCM encryption invocation, you need to pass in an IV (Initialization Vector) which must be unique.  This NIST GCM restriction is warning about not exceeding 2^32 invocations for GCM, but it does have a caveat where the restriction does not apply, “unless an implementation only uses 96-bit IVs that are generated by the deterministic construction”.  We will see in the next section that the standard way TLS implements GCM IVs is through a 96-bit IV that is generated by deterministic construction (i.e. through the TLS sequence number).

TLS GCM IVs

We find how TLS build the GCM IVs (or nonces) in this RFC -> https://tools.ietf.org/html/rfc5288.

The nonce is 96 bit (or 12 bytes):

And the nonce_explicit is deterministic and more than likely set to the 8-byte TLS sequence number:

   Each value of the nonce_explicit MUST be distinct for each distinct

   invocation of the GCM encrypt function for any fixed key.  Failure to

   meet this uniqueness requirement can significantly degrade security.

   The nonce_explicit MAY be the 64-bit sequence number.

Therefore, a TLS GCM IV implementation would normally be implemented in a way where the 2^32 invocation limitation would not apply.  If you read the entire NIST SP 800-38D document 8.3 section, you can deduce that TLS GCM would then be safe for 2^64 invocations or TLS records.

The Birthday Problem

So why does the NIST SP 800-38D document have this 2^32 invocation limit for some of the ways that the GCM IV is constructed?  It has more to do with when the IV is being randomly generated and involves the Birthday Problem -> https://en.wikipedia.org/wiki/Birthday_problem.

As this link states, “In probability theory, the birthday problem or birthday paradox concerns the probability that, in a set of n randomly chosen people, some pair of them will have the same birthday.”  One interesting fact from the Birthday Problem is that if there are only 23 people in a room, there is a 50% chance that at least two of them have the same birthday!  So if you are ever in a room with more than 23 people and you like bets that are in your favor, you have a more than 50% chance of winning the bet “Hey buddy, I bet there are at least two people in this room that have the same birthday”.

The Birthday Problem (or Paradox) shows that it can be unintuitive how high the percentage is for duplicates under certain random situations.  The Birthday Problem is also a reason why NIST recommends a limitation of 2^32 invocations for GCM IVs that are randomly generated.

Conclusion

A lot of this information was very technical.  However, hopefully it helped lay the foundation of why I believe that TLS (and subsequently IBM MQ TLS) is not restricted to the NIST GCM 2^32 invocation limitation.  Obviously, the above statement is something for security professionals (which I am not) and IBM MQ to analyze and confirm, before being used in practice.