Re: [jose] [COSE] Review of draft-ietf-jose-fully-specified-algorithms-02

[Ilari Liusvaara <[e-mail]>]

On Mon, Mar 25, 2024 at 10:23:46AM -0700, Orie Steele wrote:
> I wouldn't say there is nothing wrong with those algorithms.
> 
> Not all the changes COSE made were improvements, some of the differences
> from JOSE are mistakes, and have gone against security guidance, and leaned
> into the "a-la-carte" cryptographic suite approach, which I believe we have
> learned to avoid in protocols.

This issue has nothing to do with the changes COSE made over JOSE.

Both JOSE and COSE are very explictly "a-la-carte". Neither does
binding between indirect CEK and algorithm it is used with.

The difference between the two here is some missing critical security
requirements in COSE.

 
> In COSE, algorithms such as ECDH-ES + HKDF-256 and ECDH-ES + A128KW not
> committing to the algorithm used with the content encryption key, have
> introduced attacks, which we are still discussing how to clean up:
> 
> https://www.rfc-editor.org/rfc/rfc9459.html#section-8
> 
> As evidenced above ^ deprecation without replacement is possible... when
> there is no other option.

I see exactly two ways out for COSE:

1) Add the missing security requirements. This amounts to deprecation
without replacement for AES-CTR and AES-CBC.

Something like:

- All symmetric encryption algorithms MUST be authenticated.
- Content encryption MUST be aad-capable.

(The stuff covered by second requirement but not the first is
hilariously slow anyway.)

Implementations that do not implement the vulnerable algorithms do not
need to change.


2) Add layer-integrated KDF to COSE:

Something along lines of https://mailarchive.ietf.org/arch/msg/cose/hRPFUITlEoAgxZwW_MWDJlOlOKg/
("Doing what CMS did would work as well." part)

This means changes even in software that does not implement the bad
algorithms.


> Signatures being not fully specified seem to have less of an impact, but
> guidance moving forward should be clear, especially for PQ and Hybrid
> Algorithms.

Fully specified signatures is only about interop, not security.

The key alg parameter can already be used for forward binding from key
to signature. Which is not even needed for Ed25519 nor Ed448: those
algorithms always have such forward binding. This part can actually have
security impact.

What does not work today is reverse binding from signature to key.
The only place that needs that is algorithm negotiation in some
applications. And fully-specified algorithms is all about adding such
binding.

 
> Will be marking all the ECDSA / EdDSA / ECDH / DH stuff deprecated when a
> CRQC arrives anway.

If.




-Ilari