The primary reason for adding GCM to the crypto refresh was not efficiency, but rather FIPS compliance (as GCM is the only AEAD mode specified by NIST).<p>Then, some changes were made to how the AEAD modes (OCB, GCM, and EAX) are used, particularly to provide key separation between the various modes. In the old version, or what is now called "LibrePGP", the same session key can/could be used with different AEAD modes, and - if any of the AEAD modes turns out to be secure - a downgrade attack is possible. Furthermore, a downgrade attack from AEAD to non-AEAD could potentially be possible (à la [1]). All of that has been completely prevented in the crypto refresh, which indeed required a change in how AEAD is used.<p>However, it's GnuPG's choice not to implement those changes, not the IETF working group's choice to make changes, that caused this rift. IETF drafts change all the time, and in fact should change, in the face of possible security issues.<p>Note that v5, and the "LibrePGP" flavor of AEAD, has not been specified in an RFC (so far). Normally, it's a bad idea to generate messages according to a draft. GnuPG has done so, and now they're stuck with having to support it. Now, writing an RFC to describe that older format is also fine, but none of this should've caused a rift, and blaming that on the crypto refresh is silly.<p>---<p>Regarding EAX, it was discussed a couple times to remove it but some people wanted to keep it, so it was kept - as optional to implement. This shouldn't cause any implementation burden on those who don't want to implement it, and those who do want to use it can. I do agree it's a bit inelegant to have three AEAD modes in the spec, but again, it shouldn't cause any issues.<p>[1]: <a href="https://www.ndss-symposium.org/wp-content/uploads/2017/09/10_4_0.pdf" rel="nofollow noreferrer">https://www.ndss-symposium.org/wp-content/uploads/2017/09/10...</a>