Re: [openpgp] Backwards compatibility

[Paul Wouters <[e-mail]>]

On Thu, 19 Oct 2023, Werner Koch wrote:

> On Wed, 18 Oct 2023 14:18, Paul Wouters said:
>
>> Discussion can be found here:
>> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=merg
>
> A discussion in commit logs is not a discussion in the WG.  Commit logs
> as well as discussions in bug trackers are pretty in-transparent for
> participants of the WG because you need to actively monitor all bugs
> instead of following the mail threads.

I was being helpful so you can make your issues more concrete. From a
process point of view, individuals discuss on the mailinglist and use the
publication of drafts and draft differences to discuss concrete issues on
the list. You stopped doing that for more than a year. Coming back after
such a long hiatus and claim "every change is bad, drop this document"
is not feedback the WG can do anything with. If you vanish and not give
feedback during the process, the onus is on you to come with specific
argued proposals for changes. In case that is difficult for you to do
based on reading the latest draft and the openpgp mailing list archive,
I gave some helpful suggestions that might help you further trace the
decisions of the WG in greater detail via issue tracker items and commit
messages.

This WG has been rather meticulous in documenting every decision about
every line of text. This extra data should greatly assist you in
catching up to the WG and the various drafts it submitted.

>> I'm sure the CFRG would be interested in hearing about GCM attacks.
>
> I don't think the cons of GCM and other counter mopdes need to be
> repeated.

You have been in the rough of consensus on the topic of adding a non-MTI
of AES_GCM. If you have no further issues you would like to raise, then
I will consider this round of your feedback as processed with no further
need for changes.

>> be used by those who want and those who do not want AES_GCM, and the
>> complexity of a code point in addition to EAX and OCB is well, miniscule.
>
> This was the major reason to drop the deployed format and introduce a
> the HKDF.

I believe by "deployed format", you mean an earlier draft of 4880bis?
This "deployment" of your software was behind an optional argument
and not deployed by default. Which it should have been because it was
a draft and not a published RFC and subject to change. However, you
then choose to change this to become the new default, and other places
(like RHEL/Fedora) had to undo this change in your software, eg:

commit 146a5fe7ef862a957ef6ac35a4ec2c6308eca0f3
Author: Jakub Jelen <[e-mail]>
Date:   Thu Feb 9 16:38:58 2023 +0100

     Revert the introduction of the RFC4880bis draft into defaults

I feel that the deployment damage, insofar introduced, has been caused
by gnupg and not the WG. And that deployment damage has mostly been
countered by downstream patched of Linux Distributions. I do not believe
the WG needs to take this "deployment damage" into account.

If you have technical arguments as to why the HKDF is not the right
method to support AES_GCM and have a counter proposal, please share
it with the WG and explain why your proposal is better than the
current draft text.

>> I find it hard to believe that all other IETF protocols can safety
>> support AES_GCM, but not OpenPGP.
>
> PGP has had always higher standards than committee driven protocols and
> tried to do the Right Thing.

This draft is OpenPGP, not PGP. The first OpenPGP RFC was published in
1998. I think it is safe to say that all modern deployments of PGP are
using OpenPGP, and this committee driven protocol has been successfully
deployed and updated over time within the IETF. This draft document has
continued development using the IETF standards process.

Again, if you have any specific items for us to discuss, I and I'm
the sure others in the WG, are happy to do so. But the WG cannot really
act on blanket statements of "this document should not published".

If you feel our consensus calls have not sufficiently taken your input
into acocunt, please look at the IETF Appeal Process. A summary of which
can be found at https://www.ietf.org/standards/process/appeals/

Paul