Thanks for your support of what we’re achieving with the specification, Uri!
-- Mike
From: Blumenthal, Uri - 0553 - MITLL <[email protected]>
Sent: Sunday, September 15, 2024 3:19 AM
To: John Mattsson <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: [COSE] Re: [EXT] Re: My review of
draft-ietf-jose-fully-specified-algorithms
FWIW, I support the Ciphersuite approach, and am against a-la-carte.
—
Regards,
Uri
Secure Resilient Systems and Technologies
MIT Lincoln Laboratory
On Sep 15, 2024, at 05:30, John Mattsson
<[email protected]<mailto:[email protected]>>
wrote:
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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
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/. 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
_______________________________________________
COSE mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
