On Sat, Apr 1, 2023 at 5:09 AM AJITOMI Daisuke <ajit...@gmail.com> 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/ _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
