Re: [Last-Call] [openpgp] Last Call: <draft-ietf-openpgp-crypto-refresh-12.txt> (OpenPGP) to Proposed Standard

[Werner Koch <[e-mail]>]

Hi!

As initiater of the updated OpenPGP specification, as long time editor
of that draft, and as principal author of GnuPG (a major implementation
of the standard and de-facto successor of PGP) I see severe problems
with the draft.

Earlier versions of the following comments have been circulated in
closed groups of stakeholders.

Salam-Shalom,

   Werner
   
                   ---------------------------------
                    A CRITIQUE ON A FORK OF OPENPGP
                   ---------------------------------

                               2023-10-31


The IETF OpenPGP Working Group (WG) at some point decided to give up on
its charter to produce an updated specification and instead started to
re-invent that standard.  Whether this is in line with IETF rules is
questionable:

The charter says:
      Other work related to OpenPGP may be entertained by the
      working group as long as it does not interfere with the
      completion of the RFC4880 revision. As the revision of
      RFC4880 is the primary goal of the working group, other work
      may be undertaken, so long as [...]

Given that new features and discussions for larger updates of the
specification delayed a new RFC for many years and were the reason for
closing the WG in 2017 and re-opening in 2020, I propose to go back to
the last commonly agreed upon draft or to conclude the WG on the grounds
that no rough consensus could be found.


Symmetric Mode
══════════════

  It seems that this new scheme was introduced for the benefit of
  allowing GCM as yet another encryption mode.  GCM is a counter mode
  and, as can be seen by the large changes required, hard to get right.
  Meanwhile we have GCM in CMS (the core of S/MIME) because Microsoft
  decided to go this way.  However, OpenPGP has taken its decisions
  based on technical soundness and not based on larger vendor,
  government or committee decision.

  The WG once decided to go with OCB and EAX.  EAX was only added to
  avoid possible patent problems.  However, in the 4.5 years since the
  introduction of EAX the OCB patent expired.  Thus there is no more
  reason to reject OCB and it should be declared as RECOMMENDED mode
  with the intention to make it a MUST mode in some future OpenPGP.  It
  can also be expected that FIPS-140 will eventually allow OCB.

  My suggestion: Drop all the new AEAD ideas and use what has been
  deployed and agreed upon in this very WG a long time ago.  Further,
  turn OCB into MUST and EAX into MAY (only for backward compatibility
  to deployed implementations).


Padding Packet
══════════════

  A padding packet is introduced with the idea to mitigate traffic
  analysis.  However, it is suggested to use random data for the content
  of this packet and thus this packet opens a huge covert channel.  This
  is especially concerning for institutional users efforts regarding
  Data Leak Prevention (DLP).  Suggestions to use padding based on a
  verifiable seed, were rejected despite that this is the standard
  method to do padding.

  This padding idea has come up in discussion every once in a while over
  the last 25 years and has always been rejected because it does not
  belong into the encryption layer but into the application (plaintext)
  layer.


Changes to the ECDH Encryption
══════════════════════════════

  ECDH is the standard way to do encryption with elliptic curves.  For
  OpenPGP ECDH has been specified in RFC-6637 from 2012 and been
  implemented by PGP and GnuPG even a year earlier.  Instead of keeping
  this solid specification some details have been changed without a
  sound reason.


Proliferation for Algorithms
════════════════════════════

  The new draft not only allow the use of GCM as a third encryption mode
  but adds a couple of other required algorithms:

  • HKDF
  • Argon2 [1]
  • Optional modes [2]

  I joined the AES conference in 2000 on Phil Zimmermann's wish to talk
  about algorithm proliferation.  We agreed on pushing the forthcoming
  AES along with our MDC extension, get Twofish and so out of the focus,
  and in general resist to add new algorithms.  That is for the simple
  reason that neither PGP nor GnuPG wanted to maintain all new
  algorithms until eternity.  Later we had to do a political compromise
  to allow Camellia for the use in Japan and Brainpool curves for
  European use.  We should really stick to this and not support
  algorithms which are just a substitute for existing crypto building
  blocks.  Since added complexity makes a review harder and the larger
  codebase has to be maintained indefinitely for backwards
  compatibility.


Removal of Useful Real World Features
═════════════════════════════════════

  For example: in 2016 a 'm' flag was introduced to indicate that the
  plaintext shall be interpreted as MIME data.  This has been removed
  along with deprecating the traditional 't' flag to distingusih between
  binary and text data.  Having the ability to easily detect MIME data
  is for example required to process attachments from web mail clients
  or in air-gaped environments.

  The designated revoker feature has also been deprecated with the
  rationale that a better method is to achieve this with an “escrowed”
  revocation, pre-created by the user.  In fact, GnuPG creates such a
  revocation certificate since version 2.1 (release in 2014), to
  mitigate the common problem of a forgotten password.  But this is not
  a replacement for corporate needs: The designated revoker is an
  important feature to manage a large scale deployments of OpenPGP keys
  and acts as a CRL replacement.


Removal of Security Fixes
═════════════════════════

  Due to an implementation bug in PGP 5 the meta data of a signed file
  was not covered by the signatures.  RFC-4880 didn't fixed that for
  backward compatibility.  However, users were often surprised when they
  learned that the shown filename and file data could be changed while
  keeping the signature intact.  With the introduction of the new v5
  signature packet format, the opportunity to fix that was taken.
  However, the crypto-refresh group then introduced v6 signatures and
  removed the fix [3] with the flimsy explanation that the way to
  populate that the field is not clear in a theoretical
  encrypt-then-sign scenario and that signatures could not be detached
  and reattached (which is obvioulsy wrong).  A later proposed fix for
  v4 signature packets (Meta Hash subpacket) [4] was not considered.


Salted signature issue
══════════════════════

  Salted signature have been introduced with the idea that they might
  mitigate a choosen prefix attack in the same way as they will do for a
  certain SHA-1 based Web-of-Trust attack.  No research for that
  statement has been cited just an assumuption and a concern related to
  fault attacks on EdDSA for Wireguard-like protocols [5].  However,
  such fault attacks can be more securely detected by checking the
  signature after verification in the same way as the mitigation to
  Lenstra's attack on RSA's CRT.

  Anyway, the major concern here is that this adds another 32 octet
  covert channel to each message (and also blow the signature up by 64
  octets) In this case it is not an optional feature as with the padding
  packet.  This is a clear violation of best current practices in
  sensitive areas where signed mails are mandatory and encryption is not
  enforced (or monitored by a gateway).


Regression from Deployed Formats and Standard Behavior
══════════════════════════════════════════════════════

  In general the crypto-refresh draft tends to ignore the requirements
  of long term storage needs and considers online communication and
  software deployment pattern as the major OpenPGP usage.  Data and
  software life-cycle management has not been adequately taken in
  consideration and thus the draft regresses heavily from 30 years of
  PGP history.



Footnotes
─────────

[1] “It is RECOMMENDED that implementations use Argon2.”

[2] EAX, OCB, GCM and a way to define even more

[3] See commit 390055d408d8611bc37707f81c13215cf5a05348

[4] See commit a397df29704ab65c2565d12ec29a703efbaf7f8c

[5] https://mailarchive.ietf.org/arch/msg/cfrg/Ev8hgyojKeObXMZ7SF2m3_yekMo/


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein