Re: [openpgp] First remarks on the last I-D (Was: I-D Action: draft-ietf-openpgp-crypto-refresh-06.txt)

[Paul Wouters <[e-mail]>]

On Tue, 7 Jun 2022, Werner Koch wrote:

> The parts of the new I-D which I strongly disagree with are:
>
> 1. The new AEAD scheme.
>
>   It seems that this new scheme was introduced for the benefit of
>   allowing GCM as yet another encryption mode.  GCM is a counter mode
>   and as can be seen by the large changes required, hard to get right.
>   We do have GCM now in CMS now because Microsoft decided to go this
>   way.

Partially, this is because GCM is allowed by FIPS.

>   However, OpenPGP has taken its own decisions based on technical
>   soundness and not based on larger vendor, government or committee
>   decision.

This sentence is somewhat contradicting. OpenPGP is the work of the
IETF, so it is in a way a "committee decision". The OpenPGP Design Team
was meant to speed up to work and have a draft to discuss. That is
exactly what we are starting to do now.

>   The WG once decided to go with EAX and OCB.  EAX was only added to
>   avoid possible patent problems.  However, in the 4.5 years since the
>   introduction of EAX the patent things has expired was invalidated and
>   before the new mode will will be a MUST algorithm in a future OpenPGP
>   RFC (not in 4880bis), there will definitely be no more problem at all
>   with OCB.  I bet that by then an updated FIPS-140 will even allow
>   OCB.

If we have more indication than only your bet, that might be a persuavive
argument. But right now, GCM is the only FIPS compatible method. So I
think removing that would be problematic.

>   Thus my suggestion: Drop all that new AEAD ideas and use what has
>   been deployed and agreed upon in this very WG a long time ago.
>   Further, turn OCB into MUST and EAX into MAY (for backward
>   compatibility to deployed implementations).

That would certainly be a good option if we got confirmation about the
OCB status.

> 2. The removal of the Brainpool curved, as already explicitly listed in
>   early RFC-4880bis drafts, is not acceptable.  It may even raise
>   suspicions that a TLA was somehow involved to keep NIST curves but
>   not Brainpool.  Note I won't share such an opinion, but with crypto
>   algos we also need to look at such political things.

I personally also think that having some non-US centric options would be
good. But we do have 25519 and x448 now for that. It seems within the
IETF, Brainpool is not seeing a great adoption. But again, personally I
am fine with adding these at the MAY level. I am interested in hearing
from others on this issue. In particular, I would be interested in
people who have actually deployed using Brainpool as that might weigh in
on keeping this at the MAY level for backwards compatibility.

> There are probably other things I will eventually comment.  That will
> take more time due to the hard to handle merge request style development
> by the DT in contrast to the former step by step draft release and
> discuss process.

There is time. This draft was not meant to go out quickly into IETF Last
Call. It was meant as input to the openpgp working group for further
discussion.

Thanks for reading and commenting so far, and hope to hear more feedback
from you and others.

Paul