Mailing List Archive

Hi Kai,

On Wed, 1 Feb 2023 17:13, Kai Engert said:

> specification. However, IIUC the GnuPG developers have concerns about
> the changes that are being considered in that specifications, and IIUC

No, we have no concerns we will simply not implement the recently
heavily changed "crypto refresh". These changes were done despite that
the two major OpenPGP implementations had deployed the rfc4880bis (aka
“old crypto refresh”) changes years ago after having done interop
testing between these implementations. In fact we deployed the code in
the common and long tested way of first having the changes in the
read-part deployed and only later to enable the write-part of the
changes.

The recent changes in the “new crypto refresh” introduced a new level of
complexity mainly to support the fragile and easy to get wrong GCM
encryption mode. There is already now no more need for GCM because the
patent on the way better and more secure OCB mode has been waived. Even
for years royalty free licenses were granted in almost all domains and
for all open source implementations for the OCB mode. Which GnuPG and
RNP deployed years ago.

Complexity is the worst enemy of security and OpenPGP is already complex
enough. It is a Bad Idea to add extra complexity in whatever form. I
strongly advise not to follow the path the IETF OpenPGP design committee
has taken recently. The X.509 committee designed trouble should be
enough of historic evidence to be warned.


Shalom-Salam,

Werner


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

Hi Werner,

On 01.02.23 18:40, Werner Koch wrote:
>
> No, we have no concerns we will simply not implement the recently
> heavily changed "crypto refresh".


thanks a lot for your quick reply and for your unambiguous statement.

IIUC, RFC 4880bis contains specifications that are incompatible with the
intended IETF OpenPGP crypto-refresh, such as v5 keys.

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?

Thanks and Regards,
Kai

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

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. Sometimes consensus can not be reached. Then changes are not really possible or practical. What exactly would the downside for Thunderbird be here? There certainly doesn't seem to be any huge crisis at this point in time. Perhaps another attempt can be made in 5 years or so with a better controlled process. The issues might be better defined by then and the focus would be sharper.

Bruce

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

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.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 02.02.23 06:12, Christoph Anton Mitterer wrote:
>
> I'd kinda hope that Thunderbird follows (only) what the Working Group
> will eventually release as the next version of the standard.

Thunderbird is a tool to enable users to communicate.

If a significant amount of Thunderbird users wants to exchange messages
with users of GnuPG, then Thunderbird must not send messages that are
incompatible with GnuPG.

In the same way, Thunderbird must not send messages that GnuPG
understands, but that other major implements of OpenPGP cannot understand.

Today, my opinion is, I don't want Thunderbird to pick one of the sides.

I'm asking the OpenPGP community to work together and find a standard
that works for everyone.

Thanks and Regards,
Kai

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Thu, 2 Feb 2023 06:12, Christoph Anton Mitterer said:

> The WG seems to have done quite a good job, and crypto-refresh provides
> many things that are wanted.

Up until summer 2021.

> Is there any *real* problem about it containing GCM?! Its chapter 9.6.

Yes, I explained it. This adds a lot of extra complexity to the
protocol to mitigate for the fragile GCM. That does not affect just
GCM but also OCB.

> draft-koch-openpgp-2015-rfc4880bis-00, OTOH, lacks at least Ed448.

Will be added. Actually GnUPG supports x448 for quite some time.

> It also still comes only with S2K as KDF, despite there being
> considerably better alternatives (I mean Argon2 would be the natural

OpenPGP is a protocol used mainly for public key encryption. The S2K is
mainly used for impedance matching. Using it to make brute forcing of
passphrases harder is not its primary goal. And in fact it can't be
used in real world applications: For symmetric encryption the a full
entropy passphrase should be used. Any delays or extensive requirement
of resources (memory, CPU) is counterproductive in the real world.

You use symmetric-only encryption either for automating tasks which
requires speed and thus implementations may not be resource hog. Or for
mass sending of encrypting data to a large group of recipients. In that
case the recipients have all kind of different machine types and you
can't assume that they all have some big-memory system to quickly do the
S2K. They want to work fast and there are use cases where dozens of
messages are received per second - not a suitable target for Argon2 or
any other long running KDF.

For protecting the private key - well, this should be done but it is not
in the scope of OpenPGP, which describes an on-the-wire protocol and not
a particular implementations. Sending a private key in the OpenPGP
format is anyway not a good idea to still existing weaknesses in the
protocol - the common wisdom is to use symmetric-only encryption (with a
full-entropy password) to convey a private key. Or use another public
key.

> 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

No. The real world works in a different way. See above.

> 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

It is not a competing one but it is the state of things from summer 2021
which all paricipants of the DT had agreed upon back then. Actually
with some minor modification it is the very same as what we had in 2021
and which had been implemented and interop tested already in 2018.



Salam-Shalom,

Werner


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

Hi,

But that alone seems a poor reason to effectively split the community
> and fork OpenPGP (and by that probably help killing it).
>
> I was thinking exactly the same aside the technical part. At the end
community splits, software is not compatible any more and all is broken. It
seems it happens every 10y or so with this or that software.
Is it so hard to find a way to complete something together? (I ask it in
rhetoric way and I do not mean here GnuPG).
I hope however, you keep compatibility and user experience as top priority.

BR

On 2 Feb 2023, at 08:31, Kai Engert via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
>
> I'm asking the OpenPGP community to work together and find a standard that works for everyone.

I’d like to whole-heartedly second this. It is not only client software that will be forced to make unpalatable decisions if the standard forks, but also keyservers.

Hockeypuck relies heavily on Protonmail’s fork of gopenpgp. Protonmail are invested in crypto-refresh and will certainly implement the new RFC when it is finalised. Hockeypuck does not have the developer resources to maintain yet another fork of gopenpgp, and so will have little choice but to track upstream. This would mean that the vast majority of synchronising keyservers, including keyserver.ubuntu.com <http://keyserver.ubuntu.com/> (gnupg’s default keyserver) would not be able to handle v5 keys created by gnupg. Hagrid's dependency on sequoia-pgp means that keys.openpgp.org <http://keys.openpgp.org/> would also similarly be unavailable, leaving gnupg users without a reliable keyserver service. Conversely, keys created using the new RFC could not be processed by gnupg-wks-server, potentially forcing individual users to conform to a domain-wide policy re the split.

This is not simply a case of a standard forking, because neither side ends up owning sufficient share of the pieces to rebuild a functional ecosystem. This prospect is IMO unthinkable, and would set OpenPGP back by many years, with potentially irrevocable consequences. I don’t believe that the technical disagreements are insurmountable if there exists sufficient political will to bridge the gaps.

A

On Thu, Feb 02, 2023 at 06:12:57AM +0100, Christoph Anton Mitterer wrote:
> 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?

But why would this be a issue that needs to be addressed now? What
advantages would the new algorithms provide to the users of
Thunderbird? Would those advantages make up for the incompatibility
problems caused by the introduction of new incompatible algorithms?

For long term standards, procrastination is almost always a virtue...

>
> The WG seems to have done quite a good job, and crypto-refresh provides
> many things that are wanted.
> It has AEAD algos,

OCB has the advantage that it is faster and thus better for huge
files. The other proposed modes don't seem to have any particular
advantage. Thunderbird is a messaging application where the messages
are limited to lengths of 10s of MB. So performance is not an
issue. So it would make the most sense to stick to the existing
standardized authenticated encyption mode as specified in RFC4880 to
provide the best level of compatibility for the users. So the AEAD
modes are not really useful here.

> it has Ed25519 and Ed448,...

The advantage of curves over RSA for the users of Thundebird is the
shorter key length. The length of Ed448 is significantly longer than
Ed25519. So why standarize both? The super long keys of post quantum
cryptography would make this all insignificant so it would make sense
to wait a while and see how the quantum stuff pans out.

SHA1 seems to be mostly
> gone (in the place where it was mandatory).

How does making SHA1 gone provide any value to the users of
Thunderbird? The only attack I am aware of that relates is
Sha-mbles. It is wildly impractical the the point that most users
would not care. It can be resolved simply by upgrading existing keys
in a way that does not cause the user to lose their PGP identity. No
changes to the existing standard are required.

>
> 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.

Unless someone sends one of the users a message encrypted with EAX or
GCM. Then you have to implement it. This might happen where a user
uses an implementation that supports EAX/GCM to generate a key with
EAX/GCM in the preferences but then uses a different implementation that
does not support EAX/GCM. This is normal PGP usage as identities refer
to people, not devices. Having EAX/GCM be optional actually makes
things worse.

I have personally encountered this problem in the wild, and no new
modes have even been standardized yet.

[...]

> 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).

Argon2 seems a fairly poor choice here. It is fairly memory hungry
which could cause the users to encounter interoperability problems. An
Argon2 implementation will just blow up with an out of memory
error. There is a fairly common argument out there that Argon2 is not
optimal for situations where the time required to derive the key is
limited to less than a secone. GPG uses 0.1 seconds as a target for
example. Something cache hard might be a better choice.

Currently single core processor performance seems to be at a plateau,
so this is, again, not a crisis for any Thunderbird user.


Bruce

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

deloptes wrote in
<CAJJ4Ra+VMXBdt0B5PodfAgo75VnBNrZXUY6hnbV8BveXRE2GLA@mail.gmail.com>:
|But that alone seems a poor reason to effectively split the community
|> and fork OpenPGP (and by that probably help killing it).
|>
|> I was thinking exactly the same aside the technical part. At the end
|community splits, software is not compatible any more and all is broken. It
|seems it happens every 10y or so with this or that software.
|Is it so hard to find a way to complete something together? (I ask it in
|rhetoric way and I do not mean here GnuPG).
|I hope however, you keep compatibility and user experience as top priority.

4880bis was "current" from 2015 to somewhen in 2021 (says Werner
Koch). I as a spectator downloaded "draft 00" from July 6, 2016
on the 7th of July 2016. It includes things like Ed25519.

That is around six full years (for Werner Koch -- to me it became
apparent no sooner but 2022) --- a very long time in software
development. Software had been written and was in widespread use
for many years. That is, as i see it, especially the most widely
used implementations ship code for a long time, and are
interoperable in that. (Werner Koch has explicitly stated this in
a message in this thread.)

I am not an expert regarding OpenPGP. (And most that i did know
i have forgotten.) So there might be things that can be improved
in the OpenPGP format on top of what "V5" did say. Creating
something that is incompatible with what was envisioned as "V5"
i do not understand given the long time that passed. I would have
understood if some small compatible improvements would have been
made, and anything else been moved to a "V6". But then i had the
gut feeling that in the working group there was "laughter"
regarding this "V5" / "V6" thing in that everything is "V5" now,
and it is not what was in 4880bis for many years anyway. Other
participants of the group even create biased compatibility
overviews that looked to me moreover as (helpless, imho) tries to
build up a pressure scenario in favour of crypto-refresh (even
before there was crypto-refresh it could have been). I find this
overly uncooperative, and anyway outstanding in all the WGs
i (have) track(ed), _for_sure_.

Maybe sometimes a small step is better than a big hit.

P.S.:

#?0|kent:tls-openssl.git$ git grep -i argon master
master:doc/designs/thread-api.md: - Some algorithms are designed to be run in parallel (Argon2);
#?0|kent:tls-openssl.git$ git log --oneline master -- doc/designs/thread-api.md
d55fc027b9 Add thread pool design document (phase 1)
#?0|kent:tls-openssl.git$ git log -1 d55fc027b9 | sed -e 2,7p';d'
Author: Hugo Landau <hlandau@openssl.org>
AuthorDate: 2022-07-25 13:51:42 +0100
Commit: Tomas Mraz <tomas@openssl.org>
CommitDate: 2022-11-14 12:21:22 +0100

Add thread pool design document (phase 1)

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

On Thu, 2023-02-02 at 09:31 +0100, Kai Engert wrote:
> If a significant amount of Thunderbird users wants to exchange
> messages
> with users of GnuPG, then Thunderbird must not send messages that are
> incompatible with GnuPG.
>
> In the same way, Thunderbird must not send messages that GnuPG
> understands, but that other major implements of OpenPGP cannot
> understand.

Well that's what the open standardisation processes would have been
there for.

GnuPG, just as any other stakeholders, had (and I guess still have) the
chance to participate.
When the competing draft arose, numerous voice in the WG expressed the
wish for GnuPG to "come back" and work on areas of conflict.

If it left that processes to continue on it's own, well fine, but there
cannot be any expectation that all others follow.

Standardisation is also always about making compromises, and not about
the biggest stakeholder wins.


> Today, my opinion is, I don't want Thunderbird to pick one of the
> sides.

Which ultimately means that users of TB would still suffer
compatibility issues (with any user of incompatible new stuff from
either the standard or GnuPG) ... plus not getting any of such
modernish stuff (especially AEAD).


> I'm asking the OpenPGP community to work together and find a standard
> that works for everyone.

Well that surely would be the best, but from what one could have read
so far from representatives it doesn't seem as if that's going to
happen.
There is apparently enough desire in all that what the crypto-refresh
adds and what draft-koch-openpgp-2015-rfc4880bis-00 doesn't have, that
all it's proponents (which seemed to be a majority on the list - except
GnuPG) don't want to throw away >year of work.
And GnuPG seems to have also chosen it's path, at least from what one
could have read so far.

In the end we may just see both competing standards die and maybe
OpenPG with it.


Cheers,
Chrs.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

>
> In the end we may just see both competing standards die and maybe
> OpenPG with it.
>

this is the feeling I get following this thread. it is very disturbing.
It is happening just like many others before and from those many others it
is hard to expect any different outcome.
BR

Am Donnerstag, 2. Februar 2023, 15:49:05 CET schrieb Andrew Gallagher via
Gnupg-devel:
> On 2 Feb 2023, at 08:31, Kai Engert via Gnupg-devel <gnupg-devel@gnupg.org>
wrote:
> > I'm asking the OpenPGP community to work together and find a standard that
> > works for everyone.
> I’d like to whole-heartedly second this.

You are part of the community, I do not think that pledges will help.
What we can do is to work out the arguments, so more people can follow them
and join a constructive search for a good and well reasoned paths forward.

> Hockeypuck relies heavily on Protonmail’s fork of gopenpgp. Protonmail are
> invested in crypto-refresh and will certainly implement the new RFC when it
> is finalised. Hockeypuck does not have the developer resources to maintain
> yet another fork of gopenpgp, and so will have little choice but to track
> upstream.

Given that openpgp-2015-rfc4880bis is simpler to implement, because having
less variants, that is an argument for it. I guess that Hockeypuck/gopenpgp is
closer to support it anyway, maybe already supporting it.
What would be needed to implemented it in hockeypuck?`

Regards
Bernhard
--
www.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

On 20/02/2023 17:17, Bernhard Reiter wrote:
> Am Donnerstag, 2. Februar 2023, 15:49:05 CET schrieb Andrew Gallagher via
> Gnupg-devel:
>> Hockeypuck relies heavily on Protonmail’s fork of gopenpgp. Protonmail are
>> invested in crypto-refresh and will certainly implement the new RFC when it
>> is finalised. Hockeypuck does not have the developer resources to maintain
>> yet another fork of gopenpgp, and so will have little choice but to track
>> upstream.
>
> Given that openpgp-2015-rfc4880bis is simpler to implement, because having
> less variants, that is an argument for it.

That might have been an argument for supporting *only* -bis, but that
particular boat has sailed. We now have even more variants, not less.
The choice for hockeypuck now is not between crypto-refresh and -bis,
but between crypto-refresh and crypto-refresh-plus-bis. AFAICT, most of
the significant modifications that need to be made to hockeypuck’s own
code, such as support for longer fingerprints, are similar in both
proposals and only need to be implemented once (or once-and-a-bit). The
divergent parts, such as signature verification, are mainly in gopenpgp,
and the crypto-refresh version of that will come regardless.

> I guess that Hockeypuck/gopenpgp is
> closer to support it anyway, maybe already supporting it.
> What would be needed to implemented it in hockeypuck?`

Either Protonmail adds -bis support to their fork of gopenpgp, or
someone else re-forks their fork to to add it and commits to supporting
it long term. That "someone else" is unfortunately not going to be me as
I have neither the skillset nor spare capacity. :-(

A

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel