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

[Manu Sporny <[e-mail]>]

On Sun, Mar 26, 2023 at 1:41 PM Ilari Liusvaara
<[e-mail]> wrote:
> The problem with lack of cryptographic agility is that if a component
> is broken or proves inadequate, you are in a world of hurt.

It looks like the definition of "cryptographic agility" is failing us. :)

The article isn't arguing against having multiple algorithms to jump
to when the one's we're using today inevitably fail. It's arguing
about how we minimize the parameters that we expose to developers
while enabling us to jump to a new mechanism before the old one fails
us.

What's not under debate is: "Have backup algorithms and parameters at
the ready." (some people call this cryptographic agility)

What the article calls out, as have a number of implementers cited in
the article, is this notion of: "Enable the developers at the
application layer to dynamically switch between all the backup
algorithms and parameters." (some people call this cryptographic
agility)

That is, building all the backup algorithms into the application layer
of software and giving buttons and levers to developers that are not
trained in picking the 'right ones' is an anti-pattern. It leads to
"kitchen sink" cryptographic libraries, larger attack and audit
surfaces, downgrade attacks, and a variety of other things that have
been biting us at the application layer for years.

EdDSA largely got this right, and we need more of that, and less of
this notion of continuing this trend where we expose developers to
pick algorithms and parameters that they don't understand, which
inevitably ends up generating CVEs.

> Of all the three problems brought up, versions are worse than
> algorithms:
>
> - Versions are much more expensive.
> - Versions are much more likely to interact badly.
> - Versions are much more vulernable to downgrade attacks.

Can you define "version"? For example, do you mean "protocol version"
or "cryptographic suite version" or something else?

> And with algorithms being expensive, sometimes it is perversely
> lack of agility that makes things expensive. E.g., consider wanting
> to use Edwards25519 curve for signatures in constrained environment...

I don't think anyone is arguing against having cryptographic suite(s)
that are suitable for use in embedded contexts and other ones that are
suitable for use in non-constrained environments.

The argument is against allowing developers that don't understand how
to pick the right parameters, at the application layer, from doing so
by using language that more clearly conveys what they're picking
(rather than strings like 'A128CBC', 'A128CTR', and 'A128GCM').

> And the example of downgrade attack given is version downgrade
> attack, not algorithm downgrade attack. As hard as algorithm negotiation
> is, version negotiation is much harder.
> And in response to the statement "No one should have used those
> suites after 1999!": Better suites were not registered until 2008.

Christopher (cc'd) will have to speak to the point he was trying to
get at with this...

> And the article does not seem to bring up overloading as a solution:
> Use the same identifiers with meanings that depend on the key. The
> applications/libraries are then forced to consider the key type before
> trying operations.

Could you please elaborate more on this point, I think we might agree here.

> RS256 and HS256 is are very different things, and applications
> absolutely require control over that sort of stuff.

The point is that developers that have implemented software that have
led to CVEs didn't know that they were very different things because
of the APIs and parameters that they were using made it easy to
footgun themselves. IOW, "RS256" and "HS256" sound very similar to
them and the library APIs that they were using just did something like
"sign(tokenPayload, 'HS256', serverRSAPublicKey)"... which uses a
public key value to create an HMAC signature.

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

> And who cares about SHA-256 versus SHAKE-256 (until either gets broken,
> but nobody knows which).

The point is: Why are we expecting developers to pick these values at
the application layer?

Here's one of the problems w/ cryptographic system design today:

1. We (at the IETF) create a bunch of choices in the name of
"algorithm agility".
2. Library implementers expose all of those choices to developers in
the name of "algorithm agility" (which they've been told is a good
thing).
3. Developers footgun themselves because they pick the wrong values.

Now, the rebuttal to #3 tends to be: Well, those developers shouldn't
be touching cryptographic code or security software! ... but the
problem there is that it ignores the reality that this happens  on a
regular basis (and results in CVEs).

So the question is, can we do more, as a security community, to
prevent footguns? EdDSA (ed25519) is the sort of improvement I'm
talking about (vs. what happened w/ RSA and ECDSA). I'll argue that
the "simplicity in design" consideration is the same one that went
into Wireguard and the W3C Data Integrity work as well.

> Considering the multitude of security issues with JOSE, I don't think
> those have much to do with poor algorithm choices:

Well, we certainly agree there -- there are many reasons that JOSE has
led to the number of security issues that have come about as
developers have used the stack. Many of those reasons boil down to
questionable design choices to expose the developer to algorithms and
parameters they shouldn't have been exposed to.

> - Libraries somehow managing to use RSA public key as HMAC key (don't
>   ask me how).

Yep, exposing that selection in the way that JOSE libraries do is an
anti-pattern, IMHO.

> - Bad library API design leading to alg=none being used when it should
>   not.

Yep, "Let the attacker choose the algorithm." ... another bad anti-pattern.

> - Trusting untrustworthy in-band keys.

Yep, due to lack of language around how to resolve and use public key
information.

> - Picking wrong kinds of algorithms.

Yep, because a non-trivial number of developers using the JOSE stack
are not trained in parameter selection in that stack... multiple
footguns.

> - And numerious others where no algorithm is going to save you.

Well, there's only so much we can do... but that list is not zero, and
is what Christopher was getting at with his article. We are taking
these lessons learned into account in the W3C Data Integrity work and
trying to do better there, with a focus on a reduction in parameter
choices and eliminating the exposure of data structures that have no
business being exposed at the application layer (such as every
component of a public/private key broken out into a different
variable).

> And indeed, looking at JOSE algorithm registry, while there are some
> bad algorithms there (e.g., RS1), I would not say any of those is easy
> to pick apart if right kind of algorithms are chosen.

I'll note that "Required" JWS algorithms are: HS256, A128CBC-HS256,
and A256CBC-HS512.

A naive read at that table would suggest that those are the "safe
bets" when it comes to signing things in 2023.

Everything else is variations of "Recommended" (12 options), or
"Optional" (25 options). Are we certain most developers using that
table (or the libraries, which tend to give little to no advice around
the options) are able to make the right decision?

> The COSE registry has considerably worse stuff. E.g., WalnutDSA and
> SHA-256/64. Those might actually be easy to pick apart.

No argument there. :)

> One part of "improvement" seen with algorithms in newer stuff is that
> newer protocols/versions tends to not have the most horrible stuff
> anymore.

Yes, that's good... but how about we provide some language that says
that implementations that include "Prohibited" things lead to
"non-conformant" status. Language like that can have weight in
government conformance criteria (such as FIPS), which are then used by
large organizations, which then pressure vendors/implementers to make
the changes take effect.

IOW, aggressive deprecation of things that shouldn't be used and not
putting options forward that have questionable value (ES384, RS384,
A192GCM) should be a discussion we are having. (Perhaps that
discussion has already happened and I missed it, which is certainly
possible).

> The problem with ciphersuites is that it is easy to couple things that
> absolutely should not be coupled (and if you don't then number of
> ciphersuites explodes). And they slot well with very flawed arguments
> about "cryptographic strength matching". The end result can easily end
> up being a disaster.

Could you elaborate more on the point above, please? I'd like to
understand what you're saying at greater depth.

> The worst stuff I have seen looks innocent (with some flawed "strength
> matching" arguments), with devil in the details. Not like the impressive
> mess that is TLS 1.2- ciphersuites.

We agree that the TLS 1.2 ciphersuites are the wrong way to go. :) In
fact, that's exactly the sort of approach I'd like future work to
avoid, the W3C Data Integrity work included.

So, when I said "cryptosuite", I didn't mean "TLS 1.2 ciphersuites"...
I'm starting to think we agree on a variety of points, but the
definitions for the words we're using are different in significant
ways. :)

> And Wireguard is not linearly scalable, so it can get away with stuff
> other protocols that actually need linear scalability can not.

Can you define what you mean by "linearly scalable" -- do you mean
"the concept that as computing power increases, the hardness of
brute-forcing the cryptography has to keep pace in a linear fashion?"

Ilari, I'm a big fan of RFC8032 -- it got a lot of things right wrt.
simplicity, reduction in parameterization, reduction in implementation
errors, and is the sort of direction I hope future work at W3C and
IETF can head in. I expect that we agree on much more than it seems
initially, mostly due to the mismatch in definitions around
"cryptographic agility". :)

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