Interoperability with OpenPGP crypto-refresh

Christoph Anton Mitterer calestyo at scientia.org
Thu Feb 2 06:12:57 CET 2023


On Wed, 2023-02-01 at 22:19 -0600, Bruce Walzer wrote:
> On Wed, Feb 01, 2023 at 07:42:38PM +0100, Kai Engert via Gnupg-devel
> wrote:
> [...]
> > Does that mean, if Thunderbird wants to remain compatible with all
> > major
> > implementations, then Thunderbird must stay at the functional level
> > of RFC
> > 4880, and must not use any functionality from newer specifications,
> > neither
> > from the upcoming IETF crypto-refresh, nor items that were added in
> > RFC
> > 4880bis on top of RFC 4880?
> 
> That sounds like a reasonable approach to me.

Sounds rather like the worst approach to me. Staying at the level that
is in principle already insufficient in several places.


> Sometimes consensus can not be reached. Then changes are not really
> possible or practical. What exactly would the downside for
> Thunderbird be here?

Not getting any new algorithms?

The WG seems to have done quite a good job, and crypto-refresh provides
many things that are wanted.
It has AEAD algos, it has Ed25519 and Ed448,... SHA1 seems to be mostly
gone (in the place where it was mandatory).

Is there any *real* problem about it containing GCM?! Its chapter 9.6.
makes OCB mandatory - EAX and GCM are optional.
If one doesn't like to implement GCM because of it's fragility - don't
implement it.
But that alone seems a poor reason to effectively split the community
and fork OpenPGP (and by that probably help killing it).


draft-koch-openpgp-2015-rfc4880bis-00, OTOH, lacks at least Ed448.
It also still comes only with S2K as KDF, despite there being
considerably better alternatives (I mean Argon2 would be the natural
candidate, but probably all finalists from the PHC would be a much
better choice than S2K).
May not be a big issue for Thunderbird, but for anyone who wants to do
symmetric session keys, that's really some bad news - and IMO in no way
understandable.


Passively following the WG, many people there seem to believe that the
crypto-refresh process was quite open for anyone and seem to consider
the competing/conflicting draft at best unfortunate or rather made in
bad faith.


I'd kinda hope that Thunderbird follows (only) what the Working Group
will eventually release as the next version of the standard.
Otherwise one could just toss the whole standard and make it a
ecosystem defined by solely one party, whichever that s.


Cheers,
Chris.



More information about the Gnupg-devel mailing list