[openpgp] Choices for AEAD modes [was: AEAD and Rome]

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2022-06-13 18:19:58 +0000, Daniel Huigens wrote:
> However, if the general goal is to have as few algorithms as possible,
> I also wouldn't be entirely opposed to having only OCB.

Since the beginning of work on rfc4880bis years ago, one of the things
that we've done as a working group is to reduce constraints on
algorithmic flexibility.  For example, in
draft-ietf-openpgp-rfc4880bis-06 (back in 2018, ugh), most of the
registries were changed from "IETF Consensus" to "Specification
Required", to enable new cryptographic primitives to be added relatively
easily.

I'm not entirely convinced this is the best possible outcome, but it's a
baseline that we've stuck with for multiple years now.  It would be a
little bit odd to try to change this strategy now as we are in WGLC for
this document at long last.

I'll observe initially that we do seem to have consensus in the WG that
OCB is the mantadory-to-implement (MTI) AEAD mode, and any other mode is
optional.  I haven't heard anyone object to that baseline yet, even as
we discuss different choices about non-MTI modes.

Let me lay out the choices as i understand them with regard to the AEAD
modes here:

 a) we can leave the current table of AEAD modes as it is.  OCB remains
    MTI, other AEAD modes are explicitly optional.  The key derivation
    function maintains key separation across algorithm modes so that no
    key will be potentially misused across modes by packet metadata
    manipulation.

 b) we can strip the table down so that it only contains OCB, but
    otherwise leaves the SEIPDv2 packet framing and key derivation
    mechanisms intact.

 c) we can remove any option for choice of AEAD mode, remove the table
    of AEAD modes entirely, and simply declare that SEIPDv2 is OCB.  The
    key derivation function wouldn't include the AEAD mode, but
    presumably it would still include the packet version.

 d) we can revert to rfc4880bis-10's AEAD packet framing and key
    schedule, with its table of AEAD modes, without guarantees of key
    separation, and without GCM, but switched to OCB as the MTI mode.

 e) we could adopt some variant of rfc4880bis-10's AEAD packet framing
    and key schedule that only permits OCB, while removing the table of
    AEAD modes.

option (b) is odd: if the AEAD mode table is "specification required",
then surely GCM and EAX suffice (specifications are available), and
existing implementations already handle them.  Why should we *not*
populate the table with a small handful of known AEAD algorithms now,
and providing test vectors for them for improved interop.  Even if we
drop them from the crypto-refresh draft, I'd expect the people who want
GCM (e.g. for FIPS compliance, or for optimized implementations
dependent on WebCrypto) would want to come back and add them in again
later.  So i don't see the advantage over (a).

option (c) would be a significant change to the spec, and it moves away
from the "specification required" approach generally.  I can see the
advantage of doing so for increased interoperability, but this would be
a little bit strange to argue for in the context of also arguing for
inclusion of the Brainpool curves.  Presumably we want Brainpool curves
in the draft so that people with specific cryptographic requirements can
meet their goals with OpenPGP.  Surely the same argument holds for
things like GCM?  At least with AEAD modes we have
capabilities/preferences advertising mechanism to indicate their
preferred use, while we *don't* have any such thing for specific
asymmetric algorithms.  So arbitrary curves are even more risky for
interop than supporting arbitrary cipher modes.  Why would we want to
support inclusion of different curves but not different AEAD modes?

option (d) is problematic because a "specification required" registry
would presumably soon have GCM added by folks who want it, but the lack
of key separation between modes means that addition of a new mode like
GCM risks introducing problems with cross-mode key abuse.  This key
separation is one of the reasons that the design team moved to the
SEIPDv2 framing and key schedule in the first place.  If there's going
to be a table of AEAD algorithms, and we're going to permit new
registrations in it, having a key derivation approach that makes it
impossible to reuse a key across modes (either accidentally or through
malice) is an important safeguard.

option (e) shares the surprising change in registry strategy with (c),
it changes the semantics of an already-reserved codepoint, *and* it has
the disadvantage over (d) that no one has ever implemented this.

So from what i can see, none of the options are clear improvements on
(a), which is the approach outlined in
draft-ietf-openpgp-crypto-refresh-06.  Is there some other option that
i'm not considering?

    --dkg

PS If anyone is interested in trying to specify some kind of
   minimal-algorithm-flexibility updated version of OpenPGP, e.g. a v3
   SEIPD, v6 SKESK, v6 key, v6 signature, and v6 PKESK all with fixed
   algorithm choices, that strikes me as an interesting project for
   being able to use a very minimalist OpenPGP implementation in a
   greenfield application.  I don't know whether the WG could get
   consensus around what those algorithm choices would be, but I could
   imagine this work as something done in a rechartered working group,
   alongside the the interesting discussions we've had recently about
   algorithm expiration dates.  I would be pretty sad if that kind of
   work ended up delaying the release of the crypto-refresh draft,
   though.  I'd see the crypto-refresh draft as a kind of baseline for
   this approach.