Mailing List Archive

Standards: IETF WG proposing incompatible despite implementations and objections
Hi,

what happened the overhauled specifications of OpenPGP?

It seems that the IETF working group
plans to publish their proposal of an updated OpenPGP specification
a) even with objections present
b) and three major implementations
RNP (used by Thunderbird)
GnuPG and
OpenPGP.js (used by Mailvelope)
present that have deployed and are using a set of new functions
that GnuPG has documented and considered a rough consensus until 2021.

Some technical arguments on this mailing lists have been brought up
in the last months, but I am not sure if they have been considered by the
working group. The email discussion archived end of march at
https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
just shows procedural arguments refering to a resolution in September.

A good paths forward would be, if the technical arguments would be
re-considered, and deployed implementations.

Regards
Bernhard
--
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hello Bernhard,

On 26.04.23 15:19, Bernhard Reiter wrote:
> It seems that the IETF working group
> plans to publish their proposal of an updated OpenPGP specification
> a) even with objections present
> b) and three major implementations
> RNP (used by Thunderbird)
> GnuPG and
> OpenPGP.js (used by Mailvelope)
> present that have deployed and are using a set of new functions
> that GnuPG has documented and considered a rough consensus until 2021.

what are the new functions that RNP/GnuPG/OpenPGP.js use that you are
referring to?

Could you please list the issues that you see regarding these functions
and the proposed IETF OpenPGP specification?

Regards
Kai

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hi Bernhard and list,

On 26.04.23 15:19, Bernhard Reiter wrote:
> Some technical arguments on this mailing lists have been brought up
> in the last months, but I am not sure if they have been considered by the
> working group. The email discussion archived end of march at
> https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
> just shows procedural arguments refering to a resolution in September.
The linked thread is months after the decision was made. You can refer
to the lengthy thread where the decision was made here:

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

Ultimately the decision is a culmination of issues that were boiling
unaddressed for many years. The least subtle indicator of these that
I'm aware of is my email to the list asking Werner to step down as an
editor, that I have already pointed you towards several times now.

> A good paths forward would be, if the technical arguments would be
> re-considered, and deployed implementations.

The single one big argument is that of compatibility. And it's a really
strong argument. So strong in fact, that some folks worry that going
ahead with the new spec despite it may spell the death of OpenPGP.
And indeed - it just might.

But if you read through the thread linked above, a large part of the working
group felt that the OpenPGP community effectively maneuvered itself into
being held hostage by this argument. The options on the table seemed to
be declaring Werner dictator for life over the OpenPGP specification, or
taking the hit of the compatibility argument and try to establish an actual
working group again.

Sounds pretty extreme, I know.

But considering these extremes - I have never had the impression that
Werner,
or you for that matter, have stepped back from their position of GnuPG power
to say - whoa, if this many people are going to such lengths and are
willing to
risk so much in order to change course here - maybe it's not just all of
them
being stupid?

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
On Wed, Apr 26, 2023 at 03:19:44PM +0200, Bernhard Reiter wrote:
> Hi,
>
> what happened the overhauled specifications of OpenPGP?
>
> It seems that the IETF working group
> plans to publish their proposal of an updated OpenPGP specification

I am not sure that that would be a politically valid act at this
time. It is obvious that there is no working consensus and that the
current draft is not usable in its present form. Or at least the last
I looked. At that time there was some bikeshedding about the name of
the standard that I thought might actually be a riff on the
bikeshedding complaints as a kind of a joke. I did not pay any
attention past that.

BTW, I just checked draft 8 and discovered that it was a serious
proposal and that the name of the standard is shown as changed to
"OpenPGP".

[...]

> Some technical arguments on this mailing lists have been brought up
> in the last months, but I am not sure if they have been considered by the
> working group. The email discussion archived end of march at
> https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
> just shows procedural arguments refering to a resolution in September.
>
> A good paths forward would be, if the technical arguments would be
> re-considered, and deployed implementations.

My impression is that the ITEF process has deteriorated to the point that
meaningful change is not possible. An example from Draft 8 that is
near and dear to my heart[1]:

There was a complaint that there were too many block encryption modes
in one of the earlier drafts. There was OCFB, OCFB-MDC, OCB, EAX, and
GCM. My understanding was that EAX was only there because of the
uncertain patent status of OCB. Then GCM was added. The patent status
of OCB is very clear now and has been for something like 3 years. If
the process is capable of making substantive changes then EAX should
be removed by now, thus at least partially reflecting the concern
about too many block modes.

I checked Draft 8 and the EAX mode is still there...

Bruce Walzer

[1] https://articles.59.ca/doku.php?id=pgpfan:no_new_ae

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hello Kai,

Am Mittwoch 26 April 2023 16:34:23 schrieb Kai Engert via Gnupg-devel:
> On 26.04.23 15:19, Bernhard Reiter wrote:
> > It seems that the IETF working group
> > plans to publish their proposal of an updated OpenPGP specification
> > a) even with objections present
> > b) and three major implementations
> > RNP (used by Thunderbird)
> > GnuPG and
> > OpenPGP.js (used by Mailvelope)
> > present that have deployed and are using a set of new functions
> > that GnuPG has documented and considered a rough consensus until 2021.
>
> what are the new functions that RNP/GnuPG/OpenPGP.js use that you are
> referring to?

the ones that were implemented and put to use after RFC4880 (from 2007)
and which seems to have been a rough consensus in the IETF working group
until 2021.

I think Werner tries to document them and useful additions in
https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-01.txt
(See his email from February to this list.)

Note that I am not an authoritative source, while I do talk to folk from
g10code on a regular basis, in this matter I try to find out what the
situation is myself and document it.

> Could you please list the issues that you see regarding these functions
> and the proposed IETF OpenPGP specification?

I wish I could, even the post-2021 working group does not offer an overview
and why they deviate from those major implementations. I think it would be
most useful if those who propose something else what to what is implemented
do explain their proposal. Did you ask them?

Nevertheless there have been quite a few points posted on this list in the
last months. One example was rececked by Bruce Walzer in his previous mail:
* Too many block encryption modes and EAX still in without rational.

Best Regards
Bernhard

--
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hi Vincent,

Am Mittwoch 26 April 2023 18:26:29 schrieb Vincent Breitmoser via Gnupg-devel:
> The linked thread is months after the decision was made. You can refer
> to the lengthy thread where the decision was made here:
>
> https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/
>
> Ultimately the decision is a culmination of issues that were boiling
> unaddressed for many years.

maybe, but wouldn't it make sense to re-consider
if substancial arguments come up?

Just to consider the point Bruce brought up: Why is EAX still in?
Where can I read up on the argument on this?
(I used to read some PEPs of the python community and while there were hard
arguments made, they try to write them down for a way forward.)

> > A good paths forward would be, if the technical arguments would be
> > re-considered, and deployed implementations.
>
> The single one big argument is that of compatibility. And it's a really
> strong argument. So strong in fact, that some folks worry that going
> ahead with the new spec despite it may spell the death of OpenPGP.
> And indeed - it just might.

Both true, but it is not necessarily a "big" argument in my view.
Compatibility issues can often be addressed in parts or little steps. Or with
a plan over time. The question is: where do we want to head?

> But if you read through the thread linked above, a large part of the
> working group felt that the OpenPGP community effectively maneuvered itself
> into being held hostage by this argument. The options on the table seemed
> to be declaring Werner dictator for life over the OpenPGP specification, or
> taking the hit of the compatibility argument and try to establish an actual
> working group again.
>
> Sounds pretty extreme, I know.

If what you write is a representative summary,
then the reason for the decision would not be a good argumentation
from this fraction of the working group. It would be about argumentation
style. And however you like or dislike an argumentation style, the argument
itself does not change. So keeping EAX in the proposed spec will be a
disadvantage or not, independently of who proposes it.

What you are saying is that the working group wants to oppose Werner for
showing that they have the power and need to be taken seriously.
It maybe that those people feel this is necessary, but it is hard to see
how a technical specification will benefit from this. For this to work, they
would need to reject arguments that Werner supports just because he supports
them, not on the basis of a technical argument. In a sense they would be more
forced by Werner's views if they just based their proposal on arguments
alone.

> But considering these extremes - I have never had the impression that
> Werner, or you for that matter, have stepped back from their position
> of GnuPG power to say - whoa, if this many people are going to such lengths
> and are willing to risk so much in order to change course here
> - maybe it's not just all of them being stupid?

My view on this "power" mechanism is quite different. While I have seen power
being used (and sometimes for the bad, but often for the good) I have found
Werner sometimes to be defensive initially, but later in almost all cases,
open to follow an understandable argument. I have seen this so often over
more than 20 years that I trust Werner to have a outstanding knowledge and
development intuition about real-world usable and widely deployed public key
cryptography and its implementation. He was so often right long before I
could understand why.

I am personally are interested in getting a good standard and Free Software
implementations that help everybody. I make up my own mind and will criticise
Werner's arguments if I believe they are flawed. You will find a number of
public examples on this list. As for the OpenPGP standard:
When I have noticed the problematic situation growing, I have started looking
a bit at the situation myself to make up my mind, and I hope we get the
arguments in an overview so that more people can evaluate them. So yes, it is
very well possible that the post-2021 working group people have very good
points, and I need to keep looking for those.

It also is possible in general that many people are wrong about something that
they are fiercely fighting for. (There examples in general sciences.)

What is the case here, I don't know for sure. My current state of mind is
the summary I've posted yesterday. (A personal situtation had me unable to
work or a number of weeks where I was out of the loop.)

Do you have a suggestion what I could do?

Best Regards
Bernhard
--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
On 27 Apr 2023, at 09:04, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> Just to consider the point Bruce brought up: Why is EAX still in?
> Where can I read up on the argument on this?

AFAICT it’s still in mainly because it’s optional and nobody has formally proposed to remove it - Bruce has brought it up a few times but nearly always in conjunction with other points that don’t have consensus; there doesn’t appear to have been a specific proposal on the WG list to only remove EAX but keep everything else as is. It may be worth removing EAX if nobody intends to implement it, but if nobody implements EAX there’s no urgent need to remove it either.

>> The single one big argument is that of compatibility. And it's a really
>> strong argument. So strong in fact, that some folks worry that going
>> ahead with the new spec despite it may spell the death of OpenPGP.
>> And indeed - it just might.
>
> Both true, but it is not necessarily a "big" argument in my view.
> Compatibility issues can often be addressed in parts or little steps. Or with
> a plan over time. The question is: where do we want to head?

The competing proposals are not contradictory; the version bump has avoided that. It is possible for individual implementations to support both “v5” and “v6", even if only partially (e.g. read-only support for the “wrong” format). This would seem to me to be the most productive compromise path forward at this point, however the WG cannot officially suggest such a thing. :-)

> What you are saying is that the working group wants to oppose Werner for
> showing that they have the power and need to be taken seriously.

This is not fair. Most people on the WG have come around to the current position with extreme reluctance. If there were some way to reconcile the competing proposals even at this late stage, there would be great rejoicing.

A
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Am Donnerstag 27 April 2023 13:41:38 schrieb Andrew Gallagher via Gnupg-devel:
> On 27 Apr 2023, at 09:04, Bernhard Reiter <bernhard@intevation.de> wrote:
> > Just to consider the point Bruce brought up: Why is EAX still in?
> > Where can I read up on the argument on this?
>
> AFAICT it’s still in mainly because it’s optional and nobody has formally
> proposed to remove it - Bruce has brought it up a few times but nearly
> always in conjunction with other points that don’t have consensus; there
> doesn’t appear to have been a specific proposal on the WG list to only
> remove EAX but keep everything else as is. It may be worth removing EAX if
> nobody intends to implement it, but if nobody implements EAX there’s no
> urgent need to remove it either.

What would someone, e.g. Bruce,
need to do to remove EAX from the current draft?
I mean a simpler specification is better, so if an optional thing
is not needed, it SHOULD be taken out.

> The competing proposals are not contradictory; the version bump has avoided
> that. It is possible for individual implementations to support both “v5”
> and “v6", even if only partially (e.g. read-only support for the “wrong”
> format). This would seem to me to be the most productive compromise path
> forward at this point, however the WG cannot officially suggest such a
> thing. :-)

Thanks for pointing this out. Again I am trying to understand the situation.

[me responding to Vincent]
> > What you are saying is that the working group wants to oppose Werner for
> > showing that they have the power and need to be taken seriously.
>
> This is not fair. Most people on the WG have come around to the current
> position with extreme reluctance.

I merely infered from Vincent's impression here. I am happy you are presenting
a different view on it.

> If there were some way to reconcile the competing proposals
> even at this late stage, there would be great rejoicing.

What would need to be done to do this?
With Werner's emails and new draft since Februrary, there seems to be
something to work on and put forward arguments. Do you know if they have been
discussed in the working group since then?

The way I see is that someone digs into the technical arguments; at least to
document why different groups come to their suggestions.
Personally I may not have the time nor the expertise to really go into the
cryptographic details. who could?

Best Regards
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
On Wed, Apr 26, 2023 at 8:37?PM Bruce Walzer <bwalzer@59.ca> wrote:
> [...]
> There was a complaint that there were too many block encryption modes
> in one of the earlier drafts. There was OCFB, OCFB-MDC, OCB, EAX, and
> GCM. My understanding was that EAX was only there because of the
> uncertain patent status of OCB. Then GCM was added. The patent status
> of OCB is very clear now and has been for something like 3 years. If
> the process is capable of making substantive changes then EAX should
> be removed by now, thus at least partially reflecting the concern
> about too many block modes.

EAX was one of my favorite modes back in the early 2000s. It had a lot
of benefits with little downside. Cf.,
https://www.cryptopp.com/wiki/AEAD_Comparison .

To play devil's advocate... how does one decrypt an old message or
file encrypted using EAX mode if EAX mode is removed?

If EAX is going to be removed, then there has to be a path forward for
users. I think it is a bad idea to simply cut them off. That's bad
design and bad usability.

Perhaps it would be better to deprecate EAX mode, and suggest it not
be used for new messages. It might even be enforced by making it
runtime configurable, and defaulting to off.

Jeff

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
On 27 Apr 2023, at 16:16, Bernhard Reiter <bernhard@intevation.de> wrote:
>
> What would someone, e.g. Bruce,
> need to do to remove EAX from the current draft?
> I mean a simpler specification is better, so if an optional thing
> is not needed, it SHOULD be taken out.

Join the IETF openpgp mailing list and say “I propose to remove EAX from the current draft”.

Bruce has been an active participant on the list and has expressed skepticism about AEAD modes in general but IIRC did not object to EAX in particular. Werner and Daniel Huigens (and perhaps others, I didn’t search thoroughly) did indicate that they regard EAX as redundant but did not specifically propose that it be removed from the crypto-refresh draft, although Werner did later remove it from draft-koch. Daniel drew up a list of the differences between draft-koch and crypto-refresh, in which EAX was a line item, but it was never properly followed up on afterwards (that I can see).

AFAICT it’s just an oversight. I suspect there isn’t a good understanding of exactly how many real-world messages exist that use EAX. Daniel and Werner seem to think there are few enough.

>> If there were some way to reconcile the competing proposals
>> even at this late stage, there would be great rejoicing.
>
> What would need to be done to do this?
> With Werner's emails and new draft since Februrary, there seems to be
> something to work on and put forward arguments. Do you know if they have been
> discussed in the working group since then?


Without some resolution to the fundamental technical sticking point (whether GCM should be tolerated) I don’t see a viable landing zone at this time.

The relevant thread starts here: https://mailarchive.ietf.org/arch/msg/openpgp/_SjXfSOOtdy20nhVv79NBsDBJTc/ , it covers pretty much all the bases.

A
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hey Andrew and list,

On 27.04.23 19:04, Andrew Gallagher via Gnupg-devel wrote:
> Join the IETF openpgp mailing list and say “I propose to remove EAX from the current draft”.

That is correct. You can also make an MR on the repo and have it
reviewed, considered,
edited, and merged.

And crucially, this wasn't the case before, but is now. That is the core
issue of it all.

 - V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
Hey Vincent,

Am Donnerstag 27 April 2023 19:58:08 schrieb Vincent Breitmoser You can also
> make an MR on the repo and have it reviewed, considered,
> edited, and merged.
>
> And crucially, this wasn't the case before, but is now.
> That is the core issue of it all.

do I understand you right in that not having merge requests
available was the core issue?
If so, why?

Thanks,
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
Re: Standards: IETF WG proposing incompatible despite implementations and objections [ In reply to ]
On Thu, 27 Apr 2023 12:44, Jeffrey Walton said:

> To play devil's advocate... how does one decrypt an old message or
> file encrypted using EAX mode if EAX mode is removed?

Use GnuPG or RNP. For GnuPG I see no reason to remove EAX support for
decryption: it won't remove much code and EAX is fairly easy to
maintain. Of course we don't use it anymore encryption even if the
preferences say so. In fact GnuPG will entirely ignore the AEAD
Preferences and check only the Feature Flags to see whether all
recipients support OCB.

Do you see any reason to encrypt using EAX? AFAIK all deployed
implementations which supported EAX also supported OCB.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein