[pkg-gnupg-maint] gnupg2-revert-rfc4880bis.patch

[Daniel Kahn Gillmor]

On Sun 2024-02-25 13:51:29 +0100, Andreas Metzler wrote:
> I think our wishlist looks like this:
> #1 Stay as close as possible to upstream gnupg. Our versions should not
>   be limited, but might use different defaults. We do not want either
>   gnupg22 or gnupg24 to not be able to "talk" to vanilla gnupg22 and
>   gnupg24.
> #2 Limit the consequences of the schism. By default do not generate
>   messages/signatures/key-signatures that cannot decrypted/verified with
>   pre-schism-toolset.
> #3 Do #2 without sacrificing security.
> #4 Define the "safe" pre-schism-toolset. (e.g. gpg <= 2.2.* && rnp 0.17)
> #5 We might apply stricter criteria to gnupg22 than gnupg24, implicitely
>   assuming that we will keep gnupg24 in experimental and paln on using
>   gnupg22 as default for longer timeframe.

These seem like plausible goals, though i do note that remaining
entirely compatible, forever, with legacy GnuPG implementations
regardless of advertised featuresets will miss out on the opportunity to
improve the cryptographic primitives in use, and to interoperate with
other OpenPGP implementations that are actively involved in standards
development.  So there is something of a tradeoff here in terms of
staying "safe" in terms of breakage and staying "safe" in terms of what
cryptographic primitives are in use.

The best possible outcome would be for GnuPG to simply implement the
standards that have come out of the OpenPGP working group, so it could
interoperate with the rest of the OpenPGP ecosystem, which is
flourishing at the moment.

> I did some limited testing[2], generating keypairs with gnupg 2.4.4
> 2.2.40 and 2.2.42, importing these keys in all three versions and
> encrypting data with each version for all three versions. (The data was
> not signed). All data was decryptable by all versions (and rnp and
> sqop), however 2.2.42 differed from 2.2.40 in encrypting with OCB for
> 2.4.4 generated keys.

in particular, 2.2.42 encrypted using draft-koch-style "AEAD" packets,
which are not part of the standard developed by the IETF OpenPGP working
group.  The WG adopted SEIPD v2 instead (which GnuPG apparently does not
intend to support?) because the approach with SEIPD v2 uses a KDF to
ensure key separation between different algorithms (so an adversary who
can tamper with the ciphertext won't be able to convince a victim to use
a key intended for algorithm X against algorithm Y).  This makes it
safer to deploy different AEAD modes.  draft-koch intends there to be no
different AEAD modes except for OCB, but still provides wiggle room for
implementations (like GnuPG, as i understand it) to decrypt EAX mode,
without the KDF-based domain separation.

> Does 2.4.4 does not generate v5 wireformat or do rnp and sqop support
> it?

note that "v5 wireformat" refers to keys and signatures, but not to
encrypted data.  It's probably best to refer to this as "draft-koch
encrypted messages".  I believe 2.4.4 also generates draft-koch
encrypted messages, as does 2.2.40.  However, those messages are what
were causing problems to instances of Thunderbird :

  https://bugzilla.mozilla.org/show_bug.cgi?id=1874715

> @Daniel You provided a list to break down the usecases we need to
> consider. I think a) and c) also talk about technical issues (lack of
> KDF, v5/v3 signature aliasing). - Are these problems with draft-koch or
> implementation specific?

As i understand it, these are problems with draft-koch, not
implementation-specific concerns.  Lack of a KDF refers to the domain
separation for keys that i discussed above.  v5/v3 alias has to do with
the construction used to generate the bytestream for v5 ("draft-koch")
signatures.  The WG skipped v5 (to avoid collisions with premature
deployments of testing code) and specified v6, which does not have this
problem.  But my understanding is that GnuPG is also declining to
implement v6 keys or signatures.

If i'm asked about my preferred divergences, it would go something like
this:

0) GnuPG would by default continue to generate data that interoperates
   with GnuPG deployments going back to 2.2.27 (currently oldstable).

1) GnuPG would be capable of generating data, by default, in response to
   advertised features that correspond to features standardized by the
   IETF OpenPGP working group.

2) GnuPG would not generate data that is not standardized by the OpenPGP
   WG unless *both* (a) there is an unambiguous advertisement that the
   recipient can support it, *and* (b) the user manually asks for such
   generation.

3) When generating non-standardized data for which no advertisement is
   possible (e.g. signed messages, secret key/certificate generation)
   GnuPG should require a manual user request, and should produce a
   warning that these features may not interoperate with the rest of the
   OpenPGP ecosystem.

I still haven't reviewed the proposed patchset to see how close it comes
to these recommendations, sorry for my delay!

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240226/4908488b/attachment.sig>