Re: [CFRG] options == bad?

[Kai Mindermann <[e-mail]>]

There wasn't that much of a response unfortunately then.

-----Ursprüngliche Nachricht-----
Von: Manu Sporny <[e-mail]> 
Gesendet: Samstag, 20. August 2022 19:27
An: Kai Mindermann <[e-mail]>
Cc: Stephen Farrell <[e-mail]>; [e-mail]
Betreff: Re: [CFRG] options == bad?

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/