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

[Ilari Liusvaara <[e-mail]>]

On Sun, Apr 09, 2023 at 04:19:52PM -0400, Manu Sporny wrote:
> On Sat, Apr 1, 2023 at 5:09 AM AJITOMI Daisuke <[e-mail]> wrote:
> 
> > 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.

I don't think there are any subtle differences in approaches (those
tend to be in things like how precisely something is encoded).

Definitions being misunderstood, maybe.

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

I think most of what you call "flawed" is just having much bigger
scope than PASETO. It has some bit flawed stuff (e.g., KDF context
model), but none is what PASETO does at all.

And I have already seen the aggressive downscoping of PASETO cause
issues. And considering I only see a small fraction of the stuff,
there is going to be a lot more of that out there.


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

That very much depends on what those 10 and 1 (I presume actually 2)
variations are...

And my opinion is that version usually (excluding things like
experiments) means you screwed up (TLS 1.0, TLS 1.1, TLS 1.2, SSH1,
COSE countersigs, etc...).


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

I do not think that would have avoided any (or very few) CVE. The
CVEs are either associated with the greater scope of JOSE or do not
actually have anything to do with JOSE.

As for CVEs possibly avoided, is there a CVE for somthing actually
using RSA with SHA-1 in JOSE (to pick the worst case for picking bad
algorithm of the right kind)?


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

I think Safecurves is entierely different. It takes a set of
requirements (like not having order equal modulus) and desiderata
(like having efficient ladder) about elliptic curves and evaluates
a number of elliptic curves to that criteria.

It is not difficult to come up with new elliptic curves that do meet all
the SafeCurves criteria. In fact, one of the most difficult tasks in
doing so is actually picking efficient base prime.

And there is no wide agreement about what parameters are currently
appropriate (2023) for ECDSA. One set of experts say P-256 with
SHA-256, different experts say P-384 with SHA-384.


> 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".

However, "SOMETHING-2022" is likely not pareto-better choice than
"SOMETHING-2009". Neither of "RS256" or "ES256" is pareto-better
than the other. Ditto for "Curve25519" and "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.

Narrow down the kinds of cryptographic algorithms. Like how ACME
profiles JOSE by restricting it to signatures. And narrow down the
individual algorithms for interoperability reasons (turns out
most libraries don't just implement everything).

If the application is something more complicated, restricting the
algorithm combinations allowed can go extremely badly wrong (more
probably will go badly wrong).

 
> 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".

I think PASETO takes the position that "crypto-agility bad" and then
yeets the entiere thing, damn any flaws resulting from that.

Design that took position "crypto-agility good" and then improved on
the design to the limits would be quite different.

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

It is one thing to restrict what algorithms are included at all. HPKE
does not have RSA for instance (neither did COSE at first, but it got
added later).


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

Oh, for some users, turns out they *require* P-384 with SHA-384. No
other combination in ECDSA will do.

And that approach is not analogous to HPKE-v1, which has freely mixable
algorithms. HPKE-v2 would be some sort of radical change. There is not
even any sort of handvawing about what it would look like.


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

Actually, I think design of PASETO is a major factor. The versions are
seemingly long-term incompatible. Whereas TLS 1.2 and 1.3 are long-term
compatible. This makes a major difference on ease of migration.

And not that TLS 1.2 to 1.3 is problem-free. Much more common problem
than user doing weird stuff that is just not supported in TLS 1.3 is
users requiring some knob not implemented for TLS 1.3, forcing TLS 1.3
to be disabled.




-Ilari