Re: [jose] [COSE] Consensus on cryptographic agility in modern COSE & JOSE

[Manu Sporny <[e-mail]>]

On Sat, Apr 1, 2023 at 5:09 AM AJITOMI Daisuke <[e-mail]> wrote:
> Thank you for the information. However, this article has already been shared previously on this COSE WG mailing list, and I have sent comments to the author, Christopher, regarding this article.

+CC: ChristopherA

> https://mailarchive.ietf.org/arch/msg/cose/KqFj9VqJ0Fjk45fEPh-Ys8HZiP8/

Thank you, Daisuke, for your thoughts regarding cryptographic agility.
As I mentioned in the response to Ilari, there are subtle differences
in definitions and approaches that will benefit from further
discussion.

> Based on my experience and observations, the Versioned Protocol approach is not as bad as Ilari mentioned (in fact, I found it easy to implement and quite like it), but it doesn't seem to be working well in the real world. In fact, the version switching of PASETO has not been going well at all.

That people are not upgrading in the field is an important, but
different concern vs. people choosing to deploy 30+ variations of the
technology. As far as the latter is concerned, PASTEO got many things
right (aggressive downscoping in algorithm and parameter selection)
where JOSE was flawed right out of the gate.

What you outline as a failure in PASTEO (people aren't upgrading from
v2 to v4), is an independent (but important) concern. That is,
deployed software tends to stick around for far longer than any of us
would like it to. If we try to think about what's worse... is 10+
variations of older technology sticking around better than 1 variation
of that same old technology? It, of course, depends on what that one
variation does vs. what the other 10 do... but if we start adding
qualifiers on that 1 variation (like, it's still secure, it has a
higher level of auditing, it's hard to get implementations wrong,
etc.), then we start to identify the sort of ecosystem we'd like to
see.

Again, PASTEO got more things right than JOSE did, and if we had taken
the PASTEO approach instead (by aggressively reducing options and
parameters), then we might not have had as many CVEs as we ended up
having over the years.

Now, to be clear, I'm not arguing for "one version"... what I'm
arguing for is something along the lines of "a latest version of a
class of digital signature algorithm, versioned by year" ... like
"ecdsa-YYYY", where the designated experts decide what parameters are
appropriate for a given year and release a new "versioned" cryptosuite
every couple of years. Much like SafeCurves did almost a decade ago:

https://safecurves.cr.yp.to/

For a developer, understanding that "SOMETHING-2022" is likely a
better choice than "SOMETHING-2009" is easier than trying to
differentiate if using "RS256" is better than "ES256", or if
"Curve25519" is a better choice than "Curve41417".

> In my opinion, a better approach would be to make a generic cryptographic utility layer (like COSE or JOSE) be cryptoagility-oriented as much as possible, and then narrow down the choice of cryptographic algorithms as needed in higher-level, application-specific specifications.

Yes, exactly right, and it's the "narrow down" layer that I'm most
interested in. We tend to leave this up to the library implementers,
who have demonstrated time and time again that "implement everything"
is what they do.

In the W3C Data Integrity work, we're trying to "narrow down the
choice of cryptographic algorithms as needed in higher-level,
application-specific specifications"... but some keep insisting that
"the experts at IETF recommend cryptographic agility", when the issue
is multi-faceted and more nuanced than "crypto-agility good/bad".

IOW, for W3C Data Integrity digital signatures, what we're trying to do is:

1. Aggressively reduce the number of algorithms that can be selected
from; e.g., we're not including RSA -- systems/libraries that need it
already exist and future systems probably shouldn't use it.

2. Aggressively reduce, and ideally eliminate, developer-led parameter
selection via sane defaults; e.g., ECDSA for this year will use P-256
and SHA-256 by default. We *might* have a "strong" option that will
use P-521 and SHA-512 (but won't support 384 because there doesn't
seem to be a compelling need to). So, if a developer is using ECDSA,
they use "ecdsa-2023" or "strong-ecdsa-2023". We are considering not
even having a "strong-ecdsa-2023" algorithm identifier. This is
somewhat analogous to the "HPKE-v1" approach.

So, for ECDSA, at the application layer, you effectively have one
versioned choice for this year... and we won't release another version
until there is a compelling reason to do so. As you mentioned, even if
we were to release a new version, it's highly unlikely that people
will upgrade for years and we tend to have multi-year advanced notice
wrt. when cryptographic systems fail.

I hope that helps explain where some of us are coming from, Daisuke. I
agree with the positive things you said about PASTEO and suggest that
the reasons people are not upgrading from v2 to v4 have less to do
with PASTEOs design, and more to do with the momentum behind v2. As
we're seeing with TLS v1.2 and v1.3, people do upgrade eventually, and
what we can do in the meantime is reduce optionality such that the
software we're putting out into the wild have a chance at a thorough
audit and greatly reduced attack surface.

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