Thanks for your detailed review, Hannes. My responses are inline, prefixed by
"Mike>".
-- Mike
From: [email protected]
<[email protected]>
Sent: Sunday, September 15, 2024 1:44 AM
To: [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.
Mike> Per your review and the discussion that followed, we've added text about
the "cipher suite" terminology.
- À 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.
Mike> Indeed, you and others pointed out this inconsistency. It has been
corrected and possible dependencies between "alg" and "enc" algorithms are now
explicitly called out.
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.
Mike> Thanks - corrected
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).
Mike> We deleted the misleading text.
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/).
Mike> We added informative references rfc5990bis and draft-ietf-lamps-cms-kemri.
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.
Mike> We've added text describing the relationship to the cipher suite and à la
carte terminology.
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.
Mike> Thanks again for your support and contributions, Hannes!
Ciao
Hannes
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
