List: ietf
Subject: Re: [Last-Call] [openpgp] Last Call: <draft-ietf-openpgp-crypto-refresh-12.txt> (OpenPGP) to Propose
From: Werner Koch <wk () gnupg ! org>
Date: 2023-10-31 11:31:34
Message-ID: 87r0lbvxih.fsf () jacob ! g10code ! de
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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
["openpgp-digital-signature.asc" (application/pgp-signature)]
--
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic