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

[John Mattsson <[e-mail]>]

HI Hannes,

Thanks for your review. I include JOSE WG as well.

I think the cipher suite versus vs. à la carte is a good description for parts of the draft but not others. I don't think the discussion of having all domain parameters in the algorithm specifiers vs having some parameters in the key maps well to cipher suites. TLS 1.2 cipher suites are less specified than IKE and COSE and the term cipher suite only makes sense if there is an encryption algorithm included.

Cheers,
John




Sent from Outlook for <https://aka.ms/o0ukef> VIC 20
________________________________
From: hannes.tschofenig=[e-mail] <hannes.tschofenig=[e-mail]>
Sent: Sunday, September 15, 2024 10:43 AM
To: [e-mail] <[e-mail]>
Subject: [COSE] My review of draft-ietf-jose-fully-specified-algorithms

Hi all,

as requested, I have reviewed the document. Here’s some background information first:

Security protocols like TLS and IKEv2 perform an initial handshake to authenticate endpoints, negotiate algorithm combinations, and establish a symmetric key for securing data traffic. After the handshake, there's no need to carry algorithm information around, as the key identifier implicitly defines the algorithm in use. However, JOSE and COSE are not multi-round-trip protocols but rather building blocks for other protocols, often used in applications involving one-shot messages (such as JWTs or CWTs). It has become common practice to include algorithm information in the headers of JOSE/COSE payloads to specify the algorithm and key exchange mechanism. Despite the risk of attackers altering algorithm identifiers to deceive recipients into using incorrect algorithms with a given key, this practice persists.

There are two main philosophies regarding algorithm identifiers in JOSE/COSE headers:

- Ciphersuite Approach: The identifier refers to a meaningful combination of algorithms, key sizes, etc. This is an example from the draft: ECDH-ES using P-384 w/ HKDF and AES Key Wrap w/ 192-bit key --- this ciphersuite represents the combination of all these individual algorithms, key sizes, key distribution mechanisms, KDFs, etc.

- À La Carte Approach where individual properties are expressed independently.
Here is an example: Algorithm = AES, Key Size=128, Mode of Operation: GCM

The document aims to revise the IANA registry for JOSE and COSE algorithms to list ciphersuites, which is necessary as other specifications have assumed that ciphersuites are being used.

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.

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.

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.

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 found nits in the draft. For instance, Section 3.1.1 (which discusses direct encryption) references AES-KW, stating: "Key Wrapping algorithms impose additional implicit constraints on AAD and IV." While true, AES-KW, as defined in RFC 3394, does not have public parameters that vary per invocation. Consequently, for COSE, the protected header in the recipient structure is a zero-length byte string, which does not apply to the content encryption layer. You could call this "constraints" - it would be more correct to just state what is meant by these constraints or point to the respective section in the relevant RFC(s).

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

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.

With all that said, I agree with the overall concept of the draft. My review focuses on providing feedback on the content, and I am happy to collaborate with the authors or the group to refine and improve the wording of the text.

Ciao
Hannes