Re: [COSE] [jose] Call for Adoption: draft-jones-jose-fully-specified-algorithms

[Neil Madden <[e-mail]>]

It’s pretty clear that we’re just talking past each other now. I’ve made the points I wanted to make. I don’t think you have addressed any of them, so I still don’t support adoption of this draft. 

— Neil

On 6 Jan 2024, at 17:32, Orie Steele <[e-mail]> wrote:



Sorry this got much longer than it probably should have gotten as a reply...

Hannes, and Rich said it would be better to ask LAMPs these questions.

Instead of starting another thread, I read the latest versions of the pq related drafts to see if a pattern for naming suites would emerge, here is what I found:

SLH-DSA - https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-sphincs-plus/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-sphincs-plus/

>  The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the
   eight id-alg-slh-dsa object identifiers listed below, based on the
   security level used to generate the SLH-DSA hypertree, the small or
   fast version of the algorithm, and the use of SHA-256 [FIPS180] or
   SHAKE256 [FIPS202].  For example, id-alg-slh-dsa-256s-shake
   represents the 256-bit security level, the small version of the
   algorithm, and the use of SHAKE256.  The parameters field of the
   AlgorithmIdentifier for the SLH-DSA public key MUST be absent.

pk-slh-dsa-128s-shake
pk-slh-dsa-128f-shake
pk-slh-dsa-128s-sha2

ML-KEM (not exactly kyber fyi) - https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/

> The AlgorithmIdentifier for a Kyber public key MUST use one of the
   id-alg-kyber object identifiers listed below, based on the security
   level.  The parameters field of the AlgorithmIdentifier for the Kyber
   public key MUST be absent.

pk-kyber-512
pk-kyber-768
...

It's my position that there is basically undocumented consensus on these points:

- Protocols that require à la carte registries create them, or use an existing one.
- Protocols that can use suite registries create them or use them, and prefer them.
- Protocols that depend on registries that contain a mix, have security considerations and workarounds for the inconsistent and unreliable nature of the registry entries.

CMS, JOSE and COSE have enough similarity I would be surprised to learn that guidance for "future registrations" might be wildly inconsistent.

I would not expect to see "alg: ECDSA",  "alg: EdDSA", "alg: ML-DSA" and "alg: SLH-DSA" in JOSE and COSE... these names are nearly as useful as "alg: signature".

I am not surprised to see "id-Ed25519" and "id-Ed448" as the algorithms for "EdDSA with Ed25519", and "EdDSA with Ed448" in LAMPS.

https://datatracker.ietf.org/doc/html/rfc9481#name-eddsa" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc9481#name-eddsa

I'm co-author on the COSE WG adopted drafts for SLH-DSA, and ML-DSA (and falcon which still has a cool name).

- https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/
- https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/
- https://datatracker.ietf.org/doc/draft-ietf-cose-falcon/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-cose-falcon/

The drafts are about to expire, and the number one problem in them has been getting agreement on: how to name the "alg" values.

COSE HPKE was similarly stalled for nearly a full year on the same topic.
When it was resolved, the decision was to add (fully specified) HPKE suites to the COSE registry, not consume the HPKE à la carte registry from CFRG directly.
MLS similarly chose to create its own suite registry, instead of consume HPKE directly.

It is too bad we cannot make "alg" optional in JOSE headers, COSE was right to allow "alg" to be omitted from message headers.

It is similarly too bad we cannot make "alg" required in COSE Key and JWK, since "alg" can be anything, I really don't understand why this decision was made, properties that are not understood are ignored by convention in both JOSE and COSE.

If you want to enable a key to use any algorithm (unrestricted), even ones that are not registered (double secret unrestricted), you can do that by omitting the algorithm all together (bad), or specifying an algorithm that reflects what you plan to use the key for (you did think of this before generating the key right?),  for example:

"alg: ecdsa with sha256 and secp256k or schnorr with ... or ...." is essentially equivalent to leaving off "alg" in a secp256k1 key representation today.

No restriction, means unrestricted, which in a cryptographic key translates to less safe.

If you were producing only DER encoded ECDSA signatures with SHA256, would it not be better to say: "alg: ecdsa secp256r1 sha256 der encoded", instead of leaving off "alg", since "alg: ES256" is not der encoded?

Same goes for deterministic k, or lower s canonicalization...  instead of accidentally accepting valid ES256 signatures that might sometimes come from "alg: ES256" or "alg: undefined", would it not be better to specify things fully, "alg: ecdsa-secp256k1-sha256-determinstic-k-lower-s-der-encoded" ?

You can do this today! Perhaps implementations should simply start using "alg: Ed25519EdDSA", or "alg: Ed25519" without even registering it? 

That's basically what they are already doing, they are just ignoring the registry definitions, because they are... not helpful. 

> WebAuthn contains this de-facto algorithm definition to work around
> this problem:
>  -8 (EdDSA), where crv is 6 (Ed25519)

If enough people need interoperability at this precision, we should add registry entries for it.

Even without adding it to a registry you can restrict a key like this in JWK by a string, and in COSE Key by the "reserved for private use section" of the alg registry... but not with any interoperability guarantees.

The specifics regarding which fully specified entries to add to the existing registries, is in my opinion, the least relevant or exciting part of this draft.

Solving the problems I mentioned above is my primary concern, the less text it takes to do it, the better : )

OS

On Sat, Jan 6, 2024 at 9:22 AM Orie Steele <[e-mail]> wrote:

Inline:

On Sat, Jan 6, 2024 at 3:10 AM Neil Madden <[e-mail]> wrote:

On 5 Jan 2024, at 22:52, Orie Steele <[e-mail]> wrote:



Inline with snips (which I don't often use, so apologies if I get one wrong), and thank you again for these excellent comments:

[snip]

Right, and the point of associating the "alg" with the key is to ensure that it is only used for one thing.

That's right, but if you need to know the key type and the alg to verify, you have a "not fully specified alg".

https://datatracker.ietf.org/doc/html/rfc9053#section-2.1" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc9053#section-2.1
https://datatracker.ietf.org/doc/html/rfc7518#section-3.1" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc7518#section-3.1

ES256 is P-256 ECDSA with SHA-256 in JOSE.

ES256 is any curve ECDSA with SHA-256 in COSE.

ES256 in COSE can easily lead to cross curve scenarios, where the hash function is correct (the same), but the curve is different...

You need to negotiate the triple: [kty, crv, alg] in COSE and the singleton "alg" in JOSE.

To which my answer is, so what? You have to negotiate alg + enc for JWE, or alg + enc + crv for ECDH-ES. Applications have to be aware of these issues and deal with them.

Trying to smoosh all possible degrees of freedom into a single algorithm identifier is neither possible nor desirable. (Maybe I care about deterministic nonce generation in ECDSA, or maybe I want hedged nonces to mitigate fault attacks - should those be in the algorithm identifier? As you say, perhaps I want canonical signatures, maybe that should be in the identifier?)

This is an excellent point.

If there is a legitimate need to distinguish deterministic k, or canonical upper or lower s, then you need a way to signal that, and a registry entry should be created to enable that precision.... But if nobody needs it, or asks for it, it need not be included in the identifier (even for fully specified).

We seem to be refining away some of the vagueness that I admit, remains in the draft.
 

[snip]

I'm not familiar with this issue or what "lower S" refers to here. Do you mean some implementations spell the algorithm "Es256K" with a lowercase s?

https://github.com/Legrandin/pycryptodome/issues/759" target="_blank" rel="nofollow">https://github.com/Legrandin/pycryptodome/issues/759

https://bitcoin.stackexchange.com/questions/85946/low-s-value-in-bitcoin-signature" target="_blank" rel="nofollow">https://bitcoin.stackexchange.com/questions/85946/low-s-value-in-bitcoin-signature
 
(you replied before I hit send, but for others who might be curious, I'll leave the reference)...

I agree it's a "bug" except those are called expected behavior when they happen frequently enough... it was an analogy at any rate.

I agree with your comment, but I don't see anything better to do than enable more precision, so that implementations that are aware of it, or that come after it's available, can take advantage of it.

Given that an EC/OKP JWK already specifies the curve, this is a case where this draft doesn't make things more precise and just causes compatibility issues for no gain.

Your argument is that fully specified algorithms in JOSE & COSE are redundant to the key type requirements (kty, crv, alg = fully specified)?

This is true, that's the nature of fully specifying things, you can rely on 1 value to uniquely identify a security relevant capability.

Or you can just publish a set of keys to be used for a given purpose and put appropriate constraints on those keys. This is, IMO, the safest way to negotiate parameters: https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/" target="_blank" rel="nofollow">https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/

I can't argue with this.

The one point I would make is that because "alg" is always optional in key representations, and it can be fully or partially specified... publishing valid key representations is not sufficient to achieve interop and precision... You need to make optional fields mandatory before publishing. At a minimum whatever alg related params are not already in the key, need to go in alg, and it MUST be present, and I would also tend to recommend a content identifier / thumbprint be used for the `kid`.

The recommendations go beyond the requirements for publishing a valid COSE Key or JWK, but they are an alternative approach to addressing the same security concerns in my opinion, and perhaps they are a better way.
 

[snip]

What I mean is that this draft is motivated by saying that algorithms like "EdDSA" don't give enough information to be useful in negotiating an algorithm because one party might only support the curve Ed25519 while another supports only Ed448. Well, exactly the same thing happens with content encryption algorithms. Both parties might support "RSA-OAEP" key algorithm, but one supports only "A128GCM" and the other only supports "A128CBC-HS256". Following the logic of this draft, the issue is that "RSA-OAEP" is not fully specified,

Indeed, I agree.

 

so we should really add the following additional algorithm identifiers:

RSA-OAEP-A128GCM

RSA-OAEP-A192GCM

RSA-OAEP-A256GCM

RSA-OAEP-A128CBC-HS256

RSA-OAEP-A192CBC-HS384

RSA-OAEP-A256CBC-HS512

Not to mention doing the same for RSA-OAEP-256 and RSA1_5 and ECDH-ES and ECDH-ES+A128KW and ...

This is what I mean when I say that "fully specifying" the algorithm results in a combinatorial explosion of cipher-suite like identifiers.

Except it's 2024, and as you said, systems already understand these algorithms : )

We don't have to backport full specification for things that we think people should not use, won't use in the future or that are not being used.

? All of these algorithms are being used. 

Sorry, my point was, we don't need to add any new fully specified entries, we could just make the draft to prevent ambiguity in future registrations... or we could pick some high value targets that we think should have full specification... the working group could decide how much is worth doing.

Creating a limited number of new code points does not break old code points.

But it does create new opportunities for incompatibilities for little benefit. 

If you don't understand a new thing, you don't support it.

If you understand an old thing, you are not inconvenienced.

It addressed incompatibilities that exist today, and which other SDOs already work around, that the work arounds exist is not a reason to bless them as conventions.

If we instead took the advice in https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/" target="_blank" rel="nofollow">https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ and made it an RFC, would there be benefit?

If not, I don't think we agree on the mission objective, regardless of tactical approach.

 

 

It doesn't seem like a sensible way to do things, which is why TLS 1.3 doesn't do that any more. And this is also why OIDC, which is cited in the draft as a motivating example, has both metadata fields:

id_token_encryption_alg_values_supported

id_token_encryption_enc_values_supported

Indeed.

 

Probably OIDC should add similar id_token_signing_crv_values_supported and so on metadata fields to address this properly, rather than trying to cram everything into a single algorithm identifier.

The intention is to give a "name" to a "reasonably safe thing that is supported".

Well, I wouldn’t describe ECDSA as a reasonably safe thing under any circumstances…

lol : )

Perhaps it's time to admit that ECDSA with SHA-256 when you don't know if the curve is P-521 or P-256 is worse?
 

If changing the curve does not affect the security properties, then it seems reasonable to omit it... is that true?

I’m not sure what you’re asking here. Obviously the curve choice affects the security properties considerably. But we already have a field for specifying the curve. 

That field only exists in keys.

Your blog post points out that in messages, the attacker controls the "alg" value:

> In particular, the standard “alg” header tells the recipient what cryptographic algorithm was used to sign or encrypt the contents. Letting the attacker choose the algorithm can lead to disastrous security vulnerabilities.

> For instance, the related JWK spec already allows specifying the algorithm that the key is to be used for. The recipient looks up the key and processes the message according to the metadata.

- https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/" target="_blank" rel="nofollow">https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ 

You solved the same problem, by making `kid` mandatory and a deterministic function of the fully specified key.

I even agree your recommendation is better, as you say, some horses have already left the stable.

https://datatracker.ietf.org/doc/html/rfc8446#section-9.1" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc8446#section-9.1

>  A TLS-compliant application MUST support digital signatures with

   rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.

ecdsa_secp256r1_sha256 = ES256 in JOSE but != ES256 in COSE. (addressed in this draft)

... later:

> The following values are marked as "Recommended":
      ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
      rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
      rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
      ed25519.

Here "ed25519" is defined as... https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.1.3" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.1.3

/* EdDSA algorithms */
ed25519(0x0807),

If TLS mirrored COSE and JOSE, the algorithm would be called "EdDSA" and the curve would be unknown. (addressed in this draft)

TLS does mirror JOSE for key exchange: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.7" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.7

The fact that TLS 1.3 decided to name Ed25519 rather than EdDSA is not the point. The point is that the draft under discussion was that “alg” should be “fully specified”, which if actually consistently applied would result in alg being more like a TLS 1.2 ciphersuite. What actually now happens in TLS 1.3 is that all the things that used to be “fully specified” in a single ciphersuite identifier are now negotiated separately:

https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.1" dir="ltr" width="300" target="_blank">

<ietf-logo-card.png>

https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.1" target="_blank">RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.1" target="_blank">datatracker.ietf.org

If the actual point of this draft is the much more narrowly defined: that *signature algorithm identifiers* should include group parameters, then sure. I can live with that, even if I don’t think it’s necessary. 

But it’s not what the draft says at the moment. 

I’d also say that any such draft should just give advice for the future. Changing EdDSA to Ed25519/Ed448 retrospectively just causes pain for very little gain. 

I agree that future advice is more valuable than retrospective precision. 

TLS 1.3 algorithm name is better... "0x0807" refers to EdDSA with Ed25519.

Recent algorithms registered for use in COSE follow the same approach:

kty: HSS-LMS, alg: HSS-LMS
kty: WalnutDSA, alg: WalnutDSA

Naming the algorithm after the key (and all parameters necessary to use it) is fine.

Naming the algorithm after the process that you used the key with is not.

Because that process breaks when:
a) multiple keys support the same process, and
b) we don't know which key is supposed to be used.

You argued that b is a negotiation problem, and I agree... but that problem is compounded by a few poor names, adding a few more precise ones eliminates it, and establishes a safer convention moving forward.

Negotiate keys, not algorithms. Keys should fully specify their parameters (including algorithm). 

They are not required to, as I said in the above thread, sure a profile can fix this, but profiles build on requirements, and repeating the same guidance in every profile might hint at a problem... As you pointed out in your comment about "alg" in messages.

In COSE, "alg" is not required in message headers btw... so it's easier to follow your advice for messages, but still you are not assured of a fully specified algorithm being present in the dereferenced key (which might be a JWK, COSE Key, or some other key).

 

[snip]

My point is that "fully specified" is a vague term that depends on what you consider important and is likely to evolve over time.

Fully specified is not a vague term, it means that when I tell you EdDSAEd25519 or "0x0807", you know its EdDSA (which uses SHA-512 internally) with Ed25519 and that it won't work with an Ed448 key...

Today, if I tell you EdDSA, you don't know if it's from an Ed25519 or Ed448 key.

I’ve given lots of examples now of how “fully specified” depends on the context. You keep coming back to EdDSA, but the draft says that all “alg” identifiers should be “fully specified”. That is much broader than EdDSA. 

Thats because its the strongest example : )

We don't have to register anything new... we could cover only forward guidance, we could cover encryption or omit it, etc.
 

[snip the rest]

In short, I don't think this draft improves anything and it makes some things worse so should be rejected on that basis.

There are at least 3 parts of your arguments (thank you again), that I don't feel can be dismissed:

1. What cost for more precision is worth bearing in implementations and registry maintenance... If the current draft is "too costly" it should be rejected.
2. What should "fully specified" mean, for a series of processes, such as hash algorithm, then sign algorithm or key establishment, and then symmetric encryption.
3. Is the guidance we give on how to create new registries likely to cause problems in the future, including repeating very long debates, regarding how things were done, vs how they should be done.

ECDSA with P-521 can be used with lots of different hash first approaches.... Are all those worth registering?... No! ECDSA P-521 with SHA-1 makes no sense... arguing that it MUST be registered and that it would not be used is a straw man fallacy.

That’s not what I argued. 

You seem to be primarily arguing against the redundant code points.

I am saying the set of redundant code points registered in the draft could be 0.

 

Fully specifying things does not imply registering things that don't make sense to fully specify or to use in 2024.

Maintaining the registries is not about "what is possible". It is about "what is good for interoperability", "what lowers implementation burden", and "what improves security", and most importantly in this draft, providing guidance for new entries, that eliminates optionality, ambiguity and hopefully makes future discussions on this topic shorter and more satisfactory.

In your earlier reply you said "I’m fairly receptive to it in general, but I think it might be closing the stable door after the horse has already bolted."

It seems like part of standards is watching a different horse escape over and over again, until consensus is documented to not leave doors open : )

If you really want to close that door then the advice should be to not rely solely on a single algorithm identifier. 

Thats fair : )

I think I framed your argument here correctly in my message to the TLS list:

https://mailarchive.ietf.org/arch/msg/tls/CS_WD9StIvxOIBJSlAPJmhRMEBU/" target="_blank" rel="nofollow">https://mailarchive.ietf.org/arch/msg/tls/CS_WD9StIvxOIBJSlAPJmhRMEBU/

But please correct anything I got wrong.
 

— Neil

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

https://transmute.industries" target="_blank" rel="nofollow">https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc">

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

https://transmute.industries" target="_blank" rel="nofollow">https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc">