Re: [CFRG] options == bad?

[Manu Sporny <[e-mail]>]

On Thu, Aug 18, 2022 at 10:54 AM Kai Mindermann
<[e-mail]> wrote:
> sounds a lot like you are going for some of the ideas I presented/drafted in https://datatracker.ietf.org/doc/html/draft-kaimindermann-securecryptoconfig a while ago.

Interesting... I read through the entire draft. Yes, the concepts are
very similar, though the W3C Verifiable Credentials WG isn't trying to
go as far as establish cryptoconfigs (as you call them) for the world.
We're just trying to define them for the Verifiable Credential Data
Integrity work by building on top of established options in the
COSE/JOSE algorithms registry... but (ideally) whittling them down to
"one secure set of parameters for using a specific modern digital
signature algorithm (eg. ECDSA, EdDSA) for the next 5 years".

> Its of very big importance to leave as much of the decisions regarding crypto parameters to the crypto experts/libraries and only expose the needed parameters.

Yes, and the problem right now is that web developers (to take an
example population) are choosing from ALL of the algorithms in the
COSE/JOSE registry (without understanding what mixing any of the
parameters together really means). The incentives for
application-layer cryptography library implementers to implement
algorithms in the registries are misaligned... the more algorithms and
parameters they support, the more popular their library becomes
(because no developer wants to switch out their cryptography libraries
if they need to do something else in the future... so developers
choose something that supports EVERYTHING! ... and then go on to make
questionably uneducated guesses based on stackoverflow threads). Case
in point: https://github.com/panva/jose

We've watched in horror as our cryptography software (17M weekly
installs), which takes this "implement all the options kitchen sink
approach", is used by inexperienced developers that continue to make
some questionable parametric choices:
https://www.npmjs.com/package/node-forge

> (Of course, there can also still be an interface that allows all the possible parameters for power users / experts).

Yes, of course "expert interfaces" still need to exist... but be
deactivated/turned off by default. Ideally, cryptographic suites are
actively installed by the end developer as requirements for the
application (and are not just randomly pulled in when you install the
library). Use of deprecated/experimental features are explicitly
turned on (with warnings spewed to the console /logs if possible).

> What I have no concrete idea about yet are tunable parameters, e.g. some of the argon2id parameters may depend on the runtime environment.

Yeah, that's more difficult, and we're not currently trying to tackle
that beast. We're fairly narrowly focused on doing this correctly for
digital signatures and key exchange. We'll have some proposals for
CFRG to review in the coming months to see if we're on the right
track.

Kai, what was the response to the concepts in your suggested I-D?

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