[jose] Re: [COSE] Re: Re: My review of draft-ietf-jose-fully-specified-algorithms

[Michael Jones <[e-mail]>]

Thanks for pointing out that the problem exists both for signature and encryption algorithms, Hannes.

                                -- Mike

-----Original Message-----
From: Tschofenig, Hannes <hannes.tschofenig=[e-mail]>
Sent: Tuesday, September 17, 2024 12:46 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: [COSE] Re: [jose] Re: My review of draft-ietf-jose-fully-specified-algorithms

Hi Ilari,

just a few remarks. I disagree with your statement that the draft is about interoperability, not security. I guess it is probably a matter of wording but why would any document coming out of COSE not be about security given the type of documents being developed in the group.

You made a remark about the encryption functionality and the lack of consensus. I was at the meeting, and I heard Brian sharing his views to the group. That was it.

It makes little sense to me to just focus on digital signatures since the same problems exist for encryption algorithms as well.

Ciao
Hannes


-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Sunday, September 15, 2024 6:44 PM
To: [e-mail]; [e-mail]
Subject: [jose] Re: [COSE] My review of draft-ietf-jose-fully-specified-algorithms

On Sun, Sep 15, 2024 at 10:43:30AM +0200, hannes.tschofenig=[e-mail] wrote:
>
> Initially, the focus of the draft was on digital signature algorithms,
> but later, encryption algorithms were also included. This added
> complexity, as encryption algorithms support various key exchange
> methods. The expanded scope was discussed at the last IETF meeting.
> This expansion of scope is, however, unavoidable since otherwise the
> content of the registry is misaligned.

My interpretation of last meeting is that there is no consensus on extending the scope to encryption, mainly due to the large number of algorithms this would require.


> Mike and Orie argue that content encryption and key exchange
> algorithms must be independent of each other:
>
> "Each of these multiple algorithms must be independently fully
> specified. The operations performed by each of them MUST NOT vary when
> used alongside other algorithms. For instance, in JOSE, alg and enc
> values MUST each be fully specified, and their behaviors MUST NOT
> depend upon one another."
>
> I disagree with this perspective since these algorithms depend on each
> other. The key exchange algorithm must produce a key of the
> appropriate length for the content encryption algorithm. Additionally,
> binding them together is necessary to prevent attacks, as discussed in
> the context of COSE HPKE.

This contradicts fundamental assumptions in JWE: That "enc" and "alg"
are mutually independent, and that there is no need for binding to prevent attacks.

COSE makes weaker assumptions: Any AE(AD) algorithm is independent from all else, and that there is no need for binding to prevent attacks.

Unfortunately, the latter was left implicit, and then accidentally broken.

And even if COSE does not fundamentally assume that all algorithms are independent, it is very bad idea to have dependencies between algorithms without a good reason (basically, either the combo makes no sense, or is trivially insecure).

Most key managment algorithms in JOSE and COSE do not support binding (in some cases, it would be highly nontrival to add), and assumption "no need for binding to prevent attacks" is necessary to have such algorithms.


> Interestingly enough, later in the text they acknowledge this fact on
> page 14:
>
> "
>   In COSE, preventing cross-mode attacks, such as those described in
>    [RFC9459], can be accomplished in two ways: (1) Allow only
>    authenticated content encryption algorithms. (2) Bind the the
>    potentially unauthenticated content encryption algorithm to be used
>    into the key protection algorithm so that different content
>    encryption algorithms result in different content encryption keys.
> "
>
> I disagree with the text as currently written, as described in
> https://datatracker.ietf.org/doc/draft-tschofenig-cose-cek-hkdf-sha256/.
> I believe I understand what the authors are trying to communicate but
> it does not quite get across. Their view is purely from a registry
> value perspective and not so much from a security point of view.

Yes, The text seems confused.

What is needed in case (2) is having a KDF step before symmetric encryption to ensure that different symmetric encryption algorithms use (cryptographically) independent keys.

In some cases, COSE already has such step depending on key managment algorithm (e.g.,DKA and direct+KDF), but not all (e.g., any non-direct algorihm).


> Section 3.2's API descriptions are incorrect. For example, most
> ciphers used for content encryption in COSE and JOSE are AEAD ciphers,
> and their API does not align with the description in Section 3.1.1.

I think that description is strange, but not flat out incorrect, as it does allow for additional aad input.

All JOSE content encryption algorithms are AEAD, as JWE absolutely requires that.

COSE does allow using non-AEAD for content encryption, but all the current algorithms suitable for content encryption are AEAD, and this state of affairs is expected to continue. Moreover, using any non AD- capable encryption at layer0 is of questionable use.


> In Section 3.2.2, it appears that the document creates new KEM-
> definitions and their APIs, despite several existing IETF
> specifications that could be referenced. For example, text could be
> copied from RFC 5990bis (see Section 1.2 of
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/)

Looking at section 3.2.2:

What the heck is "Key Establishment with Direct Encryption"? Neither JOSE nor COSE define such term, and it looks like an oxymoron anyway.

Then some references to "JWE Protected Header" are incorrect and should be "JOSE Header" instead.

Then the stated method of constructing a fully-specified algorithm in JOSE does not work, as it breaks fundamental assumption in JWE (the indepence of "enc" and "alg").


> Finally, I have concerns about the terminology used in the draft.
> For instance, I am not convinced that introducing the term
> "polymorphic" is a good idea, as it is not used in the security field.
> In the IPsec/IKE discussions I have seen the terms Ciphersuite vs. À
> La Carte being used.

This draft is about interoperability, not security. It does define what it means with "polymorphic", and it is not quite the same as "À La Carte".

In fact, "fully-specified" can be less secure than "polymorphic", as "polymorphic" might make some critical security checks into required for function. Unfortunatly, this has proven to not be theoretical.




-Ilari

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