[jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms

[Michael Jones <[e-mail]>]

Thanks for your WGLC feedback, Ilari.  The authors have attempted to incorporate it in draft -03.  Here's a few points specific to your comments:

Text was added to https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-03.html#name-algorithms-for-signing-with on the ability to register key-size-specific RSA algorithms in the future, if needed.

The text on KEMs was removed, since it wasn't applicable to any currently registered polymorphic algorithms.

And of course, a lot of the new text in -03 addresses fully-specified encryption algorithms, including registering a small number of fully-specified ECDH algorithms for JOSE and COSE.

Finally, thank you for your observation that this work is about improving interoperability.  I agree.

				Thanks again,
				-- Mike

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Tuesday, May 7, 2024 2:30 AM
To: [e-mail]
Subject: [jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms

On Mon, May 06, 2024 at 02:40:32PM +0100, Neil Madden wrote:

> So the draft needs to be substantially rewritten to reflect what it is 
> actually now proposing. It also, ironically, needs to flesh out what 
> “fully-specified” means, because that description is very vague.
> (eg it seems key sizes do not need to be specified, but curves do, and 
> it refers to KDFs and other things that are not in scope).  Perhaps 
> rewrite it as a more focused draft saying that *elliptic curve
> signature* algorithms should specify the curve specifically. 

I find the distinction between "fully-specified" and "polymorphic"
clear. It is about if "alg" value alone is enoguh to specify the cryptographic operation the layer performs.

For RSA, it is still the same formula regardless how many bits e, d and n have, so RSA key size does not factor in. Thus, RS256 can be fully specified regardless of lacking key size.

And I think most RSA verifiers should be able to deal with any key size multiple of 8 bits between 2048 and 8192 bits. However, there are flawed RSA key generators that can generate keys with one less bit than intended (e.g., product of two 1024-bit primes might only be 2047-bit).

For EdDSA, there is huge difference between Ed25519 and Ed448, so those are definitely different crpytographic operations.

For ECDSA, one could argue if curve factors into cryptographic operation performed or not. However, for each curve, there is single preferred hash function, and anything else gives interoperability problems.
E.g., P-256 should always go with SHA256. So those should still be treated together.


However, there is at least one place where the document itself seems to get get confused about this: Section 6.3, which applies incorrect implication.

What fully-specified means for KEMs is "alg" implying all the parameters of the KEM (i.e., the KEM is fixed-parameter). This has nothing to do with any KDF, which might not even exist (e.g., Kyber/ML-KEM), or even if it does, it is an internal detail of the KEM.


> The entirety of section 3.3 should also be removed, or else 
> substantially rewritten to reflect that the advice doesn’t apply to 
> encryption algorithms. I would delete it.

Yeah, that needs to be scoped to apply to signatures only.


Then section 5 might also need adjustment. However, the prohibition on algorithms interacting should remain, as having algorithms interact with one another in any sort of new ways is very bad idea (it makes complexity absolutely explode, and can easily cause nasty interoperability problems that are not readily apparent).


> Section 6.2 says it is not sure what to do, suggesting the draft isn’t 
> ready for WGLC.

That looks to be leftover from scoping this down to just signatures.


> The security considerations in section 7 are nonsense. How does an 
> attacker get to “choose algorithms” with current EdDSA?

Yeah, this does not reduce attack surface, it increases it, by allowing implementations not consider key subtypes. And doing exactly that has caused criticial vulnerabilities in the past.

This stuff is not about security, it is about interoperability.




-Ilari

_______________________________________________
jose mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]