Maybe “a la carte” and “prix fixe”? Recognising that there will always be new items on the menu (eg key/message commitment, canonical signatures, to name some recent additions to the security plat du jour).
— Neil > On 16 Sep 2024, at 10:53, [email protected] wrote: > > Hi John, > > I agree that the term “ciphersuite” is not 100 % ideal either. However, even > in TLS there is the option to not include an encryption algorithm with the > introduction of RFC 9150. > > How about „fully specified“ and “a la carte” as the two categories? > > Ciao > Hannes > > From: John Mattsson <[email protected]> > Sent: Sonntag, 15. September 2024 11:30 > To: [email protected]; [email protected] > Cc: [email protected] > Subject: [COSE] Re: My review of draft-ietf-jose-fully-specified-algorithms > > 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: [email protected] > <mailto:[email protected]><[email protected] > <mailto:[email protected]>> > Sent: Sunday, September 15, 2024 10:43 AM > To: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > 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/ > <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/ > <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 > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
