What is IBM's recommendation on the use of Diffie-Hellman Group 1 for IPSecurity?

According to the IBM z/OS 2.2 Migration book, "Diffie-Hellman group 1 is considered a weak algorithm and is not recommended."

During the phase 1 key exchange, the DHGroup parameter on the KeyExchangeOffer statement in the IPSec policy specifies the Diffie-Helman group used to determine the strength of the key used in the key exchange process. The higher the group number, the stronger the key used. The DHGroup value Group1 specifies that Diffie-Hellman group 1 is used during the phase 1 key exchange. Group1 is a 768-bit group. The DHGroup value Group2 specifies that Diffie-Hellman group 2 is used during the phase 1 key exchange. Group2 is a 1024-bit group.

The z/OS 2.2 Migration book also points out that the default value for the DHGroup parameter of the KeyExchangeOffer statement of the z/OS Communications Server IPSec policy has been changed in z/OS V2R2 from Group1 to Group2:

"In z/OS V2R2, the default value for the DHGroup parameter on the KeyExchangeOffer statement in the IPSec policy is changed from Group1 to Group2. If you have an IPSec policy, determine whether this change effects your policy. If you use the IBM Configuration Assistant for z/OS Communications Server to configure your IPSec policy, an explicit DHGroup value is generated on every KeyExchangeOffer statement. A default value is not used.... "If your policy is not generated by IBM Configuration Assistant for z/OS Communications Server, search your IPSec policy files for any KeyExchangeOffer statements that do not specify a DHGroup parameter. If you find such a KeyExchangeOffer statement, your policy is effected. If you require the DHGroup value to continue to use the previous default of Group1, update your policy to explicitly set the DHGroup parameter to Group1. If you want to use the new default, you need to coordinate with the owners of each remote IKE peer that is associated with the z/OS policy changes to ensure that the remote peer's policy is compatible with the z/OS changes. If the z/OS policy changes so that it is incompatible with the remote peer's policy, the IKE daemons will no longer be able to successfully negotiate IPSec tunnels."