Re: Excessive Optionality in Cryptography Anti-Pattern (was: Re: JSONWebSignature2020 vs JcsEd25519Signature2022)

Inline:

On Fri, Mar 10, 2023 at 11:20 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Fri, Mar 10, 2023 at 11:42 AM Orie Steele <orie@transmute.industries>
> wrote:
> >> Your article clearly calls out one of these highly problematic myths
> >> -- that "algorithmic agility is a good thing", and cites multiple
> >> practicing cryptography and security experts (at IETF and elsewhere)
> >> that have been speaking out against the "algorithmic agility" myth for
> >> the better part of the last decade.
> >
> > Citation needed.
>
> The citations are throughout Christopher's article (and all of them
> are listed at the bottom).
>
> > Here is counterpoint from IETF regarding HPKE, which is one the most
> popular new crypto related work items, and has taken the opposite approach:
>
> Let's dissect your example...
>
> > "In recent work here, COSE HPKE <
> https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/> is however going
> for the full agility that you criticize.
> https://mailarchive.ietf.org/arch/msg/cose/4HkrEz2io72eGHss5tFI-wyiQ-E/"
>
> Really? That does not seem like the case at all (in reading the spec
> and the registries in their totality).
>
> HPKE picks: 2 KEMs, 1 KDF, and 2 AEAD methods:
>
> https://www.iana.org/assignments/hpke/hpke.xhtml


>
> So, in reality, quite far (and constrained) from where the JOSE stack
> is today wrt. algorithmic agility. Granted, HPKE still has a bit too
> much parameter variation in the registry, IMHO, but it's certainly not
> the mess that is the JWA registry:
>
>
> https://www.iana.org/assignments/jose/jose.xhtml#table-web-signature-encryption-algorithms
>
> There was a SIGNIFICANT down selection of algorithms and parameters in
> HPKE. Now, the counter-argument might be: "Oh, but just wait, the HPKE
> registry will fill up with all sorts of questionable algorithms in
> time." ... but I expect that Richard and Chris will fight hard against
> that happening.
>
>
Agility is not the "length of the registry" alone... It is the valid
combinations a conformant implementation is allowed to support, for each
growth in a registry.

Consider:

https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/

```
 encapsulated_key = [
          kem_id : uint,         ; kem identifier
          kdf_id : uint,           ; kdf identifier
          aead_id : uint,        ; aead identifier
          enc : bstr,               ; encapsulated key
      ]
```

True, every registry entry increases the agility of the envelope format,
but when the registries are for parameters,
the agility increases at a faster rate, than if they are "named cipher
suites" like ES256 or ECDH-ES+A256KW.

Perhaps you mean to say that registry maintainers determine if new kinds of
agility are "good" or "bad" ?

I think you might be missing the point on HPKE vs JOSE agility...

Speaking in general terms.... In JOSE we have:

ECDH-ES+A256KW... // a single named cipher suite registry entry,
encapsulating a specific KDF, etc...

With HPKE we have:

DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM // a combination of
several parameter registry entries, one of which is a specific KDF

The difference is HPKE invites leveraging parameter registries instead of
creating "alg" or "cipher suites".

You don't have a "named alg" ... you have an "alg family (HPKE) and
parameters from a registry (Kem, Kdf, Aead)"... (reminds you of RSA in JOSE
a bit... doesn't it....)

HPKE has more agility than JOSE.... not less... because it uses registries
for parameters... not named cipher suites (like JWA).

The existence of HPKE is exactly the point... they DID NOT just re-use
> existing IANA registries, but created their own (because the entries
> are different) and then made a conscious decision to not pull every
> KEM, KDF, and AEAD into the registry.
>
>
That is because there were no registries to reuse for the more agile
parameterized approach, the existing registries had chosen to internalize
parameters in an attempt to cut down on agility....
This prevented their reuse, and forced HPKE to create the parameter
registries it needed, increasing its potential agility... :
https://www.rfc-editor.org/rfc/rfc9180.html#name-iana-considerations

In my opinion, establishing a registry for parameter classes signals an
intent to increase agility much more than encapsulating parameters in a
named cipher suite.

Jumping ahead, if data integrity proofs think "canonicalization" is
a positive crypto agility "extension point"...
establish a registry to increase agility... otherwise...
encapsulate the parameter in a named cipher suite.

^ same argument applies to the hash function and signature scheme chosen...

The current data integrity proof approach is cipher suite based, not
parameter registry based.


> > I think folks using the word "agility" in so many different ways is
> making the argument "against cryptographic agility" nearly meaningless at
> this point.
>
> Just because people are asserting that the waters are being muddied
> does not mean that there isn't a problem. Yes, some people are
> misusing the terminology, and the terminology is also a bit vague and
> overly broad. However, that a term is vague or being misused does not
> invalidate the argument that there is a problem.
>
> As far as I can tell, the term (as used in Christopher's article), is
> being used in a way that is mostly aligned with the definition in the
> Wikipedia entry:
>
> https://en.wikipedia.org/wiki/Cryptographic_agility


>  Cryptographic agility (also referred to as crypto-agility) is a practice
paradigm in designing information security protocols and standards in a way
so that they can support multiple *cryptographic primitives* and
*algorithms* at the same time.

^ this describes nearly every envelope format including, PGP, JOSE, COSE
and even... ACDCs and Data Integrity Proofs.

From the wikipedia article:

> Then the systems implementing a particular standard can choose which
combination of primitives they want to use. The primary goal of
cryptographic agility was to enable rapid adaptations of new cryptographic
primitives and algorithms without making disruptive changes to the systems'
infrastructure.

HPKE created registries for primitives and algorithms.

JOSE created registries for cipher suites... Cipher suites internalize
primitives such as KDFs, or algorithms and primitives, such as
EdDSA (requires sha512) or ES256 (requires sha256).

Data Integrity relies on registries for cipher suites... Which
internalize primitives such as hash functions,
canonicalization functions and digital signature algorithms, such as
EdDSA (requires sha512) or ES256 (requires sha256).

HPKE has more agility than JOSE, which has more agility than Data
Integrity...

In HPKE, you add a new parameter to a registry, and agility goes up.

In JOSE, you add a new named cipher suite, for every dependent parameter
you need, and agility goes up.

In Data Integrity, you add a new named cipher suite, for every dependent
parameter you need, with extra parameter options for hash function, and
canonicalization function, and agility goes up.

Is the higher agility in HPKE evidence that IETF believes "excessive crypto
agility is bad" ?

... seems the opposite is true.

I read HPKE's design choices as asserting that named cipher suites
encapsulating lots of implementation details, and causing registries to
grow according to combinatorics, is the "old way"
... and parameter registries are the "new way", because they are simpler to
maintain and support better cryptographic agility.

The trend is towards smarter agility at IETF.

Regards,

OS


> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>