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

[Ilari Liusvaara <[e-mail]>]

On Sun, Apr 09, 2023 at 02:26:28PM -0400, Manu Sporny wrote:
> 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.

But is that backup algorithm actually usable? Or just for show and turns
out to cruble when most needed?


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

I would think that actually usable backup algorithm(s) would imply
the latter.

However, crypto agility does not imply actually having backup algorithms
defined.

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

Ignoring performance or interop, picking 'right ones' is mostly picking
algorithms that are not weak.

I have term "abstraction rot". One form (there are others as well) is
accumulating parameters that interact in bizarre ways. Cryptographic
algorithms do not tend to do that.

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

It doesn't inevitably lead to CVEs.

Consider for example exposing ECDSA complete with all the following
parameters:

- Curve: P-256, P-384, P-521, Brainpool256, Brainpool384, Brainpool512,
  Wei25519, Wei448.
 
- Hash: SHA-256, SHA-384, SHA-512, SHA-512/256, SHA3-256, SHA3-384,
  SHA3-512, SHAKE128, SHAKE256.

Interop disaster? ECDSA+SHA3 -> interop disaster. Likely to generate
CVEs? No.

I think there is need for a new signature algorithm that is considerably
more flexible than ECDSA, but does not end up being the interop disaster
that is ECDSA when combined with SHA-3.


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

Protocol versions mainly, and also cryptographic suite versions.


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

Considering the high requirements for crypto even in constrained
environments, if of the right kind, that crypto is likely usable even
in non-constrained environments.

The difference is that non-constrained environments can also support
the higher-security stuff.


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

Version numbers or year numbers are much more opaque than those
names. One can almost guess what those three are from the names (one
sure as heck can't from something like enc-2022), and if not, take a
look at the descriptions in registry.


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

Things like "EdDSA" in JOSE meaning two different things depending on
the key (but folks do not seem to like that very much).

With long-term keys, there could even just be one algorithm: "the key
tells what it means" (a.k.a. abstract keys). But this will not work
with short-term keys.


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

One would think that would blow up somewhere, because either the key
members will not match (Where's "k"???), or key methods will not match
(MAC with RSA key???). I suppose weak typing is involved somehow.

Or maybe I have just been writing too much Rust code. :-)

In old bad days, a number of different mail user agents had a way to
make the application try to encrypt using DSA public key. It invariably
blew up somewhere (with not helpful error message).


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

It is definitely bad place. But is it the least bad place?


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

It is scope that is the main driver, not algorithms.

If JOSE only supported one algorithm of each kind but had the same scope
as it does now, it would still have pretty much all the same CVEs.

However insufficient that would be, it would still need all the same
crypto-agility mechanisms.

TLS 1.3 does not have any backup in case SHA-2 fails. However, it has
the crypto-agility to add actual backup algorithm.

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

I think the main driver for CVEs there is bad library APIs.

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

I don't think the main problems with RSA and ECDSA are connected to
those having parameters, but to other things.

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

I meant the exact opposite: I think most security issues are not due to
that. Cryptography is typically bypassed, not penetrated.

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

Regardless how it is exposed, that should never work (and I can't even
guess how the libraries made it work).

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

The correct way to handle alg=none in library is to unconditionally
consider it invalid signature or MAC.

And in practice, letting attacker choose the algorithm is not that bad.

> > - Trusting untrustworthy in-band keys.
> 
> Yep, due to lack of language around how to resolve and use public key
> information.

This is something much more basic: Not considering at all what key
should be trusted for.

And JOSE certainly was not first there. XML Security was infamous for
software doing stuff like that.

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

This is not doing something like picking ES512 or RS384, when one should
be using ES256 or EdDSA. It is mistakes like picking HS256 instead, which
has drastically different properties.

If one is to fault JOSE specs for that, it is making MACs and signatures
too similar.


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

This is kind of mistakes where no amount of reducing parameters or
not exposing internal formats is going to do anything. Because as far
as cryptography is considered, everything is fine.

For instance, ACME spends way more stuff on application-specific
additions needed for security (multiple sections) than profiling
down JOSE for very high standards (part of one section).


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

Looking at those "Required" algorithms, it is easy to choose wrong
kind of algorithm... Which is much worse than choosing even the very
worst optional algorithm of the right kind.

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

Non-conformant with what? FIPS already resticts what algorithms can be
used.
 
Unfortunately, FIPS modes have number of undesirable side effects. Those
really should not be used unless there is some compliance reason
requiring FIPS mode.

And getting implementations to remove support for anything is a very
slow process.


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

There is a big difference between a bad algorithm and an algorithm with
questionable value.

The first can haunt implementations for a long time, causing security
problems. The second tends to at worst cause interoperability (or
performance) problems.

I still see EXPORT/single-DES in TLS 1.2. Even if it was clear over two
decades ago that those are hopelessly weak.


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

Things like only allowing 128-level key exchange (e.g., X25519) or
128-level symmetric encryption (e.g., AES-128) with 128-level long-term
signature key (e.g., Ed25519).


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

Well, the TLS 1.2 stuff is merely impressive, not actually that bad,
at least compared to some other stuff.


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

What I think word "cryptosuite" means is something like what MLS seems
to do. Either I misunderstand it really badly, or it is horribly flawed.
I really hope it is the first. Oh, and it does have "strength matching"
arguments.

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

The cost of system is proportional to number of endpoints, not number
of interactions.

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

Unfortunately it also has a number of mistakes. Causes were mostly
folks wanting weird things, not realizing the trouble it would
cause. 



-Ilari