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

[Stephen Farrell <[e-mail]>]

Hi Werner,

The high level answer to pretty much all your points below is that
these issues were raised by you as the WG did it's work and the WG
decided to proceed as it has.

In particular, in September 2022 we (as chairs) polled the WG [1] to
see if people preferred to continue with the WG draft (that's now the
subject of this IETF last call), or to adopt the draft you wrote (on
the lines below) as an alternative. After many participants had chimed
in the WG explicitly chose to continue and to not adopt the set of
changes you prefer.

Cheers,
Stephen & dkg (as openpgp WG chairs)

PS: Normally we'd bemoan the fact that someone was re-raising issues
already discussed in the WG during IETF LC, but in this case we do
think it's fair for Werner to bring our attention to the fact that
the main developer of a significant implementation is in the "rough"
part of rough consensus. That's regrettable of course, but the WG
did explicitly consider that during the work.

[1] 
https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/

On 31/10/2023 11:31, Werner Koch wrote:
> 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/
> 
> 
>