|
Hi Brian, Sorry it took a couple weeks for us to get back to you. See comments below with [JG] for details. From: Brian Weis via Datatracker <noreply@xxxxxxxx>
Reviewer: Brian Weis Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written primarily for the benefit Reviewer: Brian Weis
Review result: Has Nits
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
The summary of the review is Has Nits.
This document defines the usage of Key Encapsulation Mechanism (KEM)
algorithms for CMS. In particular a content encryption key (CEK)
used to protect CMS content is protected by a key encryption key
(KEK), which is itself derived from a shared secret (ss). The shared
secret is generated using KEM public key cryptography algorithms.
Some clarification would improve the document.
1. There are three symmetric keys defined here, which are not always
referred to by the same words. It would help the reader if they
were used consistently. I think the easiest way to resolve this is
to include the acronym after first use (e.g., "content-encryption-key
(CEK)" and then use the acronym each time afterwords. Here are
some cases where an inconsistent key name is used.
-- "originator-generated content-encryption key" -> "CEK"
-- "pairwise shared secret" in Section 2 is apparently "ss" in
Section 1.
[JG] Sure, these clarifications make sense. We can make that change. 2. Section 1.3 essentially states that CMS version numbers are
unreliable, and as long as the CMS can be evaluated the version
number is irrelevant. I assume this is a generic CMS issue unrelated
to this document and is current practice. If so, that might be worth
mentioning.
[JG] Hmm… I don’t read it this way. I don’t think we are saying the version number is irrelevant. If anything, it is an ASN.1 parsing issue that is unrelated to this document. Linda had some comments about this section as
well, and the current text proposed is the following:
As described in {{Section 1.3 of RFC5652}}, the major data structures include a
version number as the first item in the data structure. The version number is
intended to avoid ASN.1 decode errors. Some implementations do not check the
version number prior to attempting a decode, and then if a decode error
occurs, the version number is checked as part of the error handling routine. This
is a reasonable approach; it places error processing outside of the fast path. This
approach is also forgiving when an incorrect version number is used by the originator.
Does this update address your comment?
3. Section 2 states "The originator randomly generates the
content-encryption key, and then all recipients obtain that key."
This is the first reference to the content-encryption key, and it
isn't clear yet how it's distributed (e.g., is it out of band,
within CMS, etc.). It would be nice to be more clear in that sentence,
for example by appending it with something like "... as an encrypted
object within the KEM CMS object."
[JG] We had this comment from the previous reviewer, so we will clarify.
“… as an encrypted object within the KEMRecipientInfo encryptedKey explained in section 3.” 4. Section 2 list item 2 for the originator and recipient both
mention "data that is sent in the clear". Is this the "ukm" in the
KEMRecipientInfo structure? If so, instead of "sent in the clear"
text such as "included in the CMS structure". Otherwise, one wonders
whether the cleartext is integrity protected and could be changed
by a man-in-the-middle.
[JG] Clarity is good. How about this:
“The key-derivation function is used to derive a pairwise key-encryption key, called KEK, from the pairwise shared secret and other data that is optionally sent in the ukm field.” 5. Section 3, "rid" definition. The text is long, and it would be
helpful if it also include an object definition defined showing the
two alternative (such as is done in Section 4).
[JG] The text is essentially identical to 5652 (Except for the first sentence). I just noticed a typo in the first sentence of our document, so we will fix that, but I don’t see a reason to change anything else.. 6. Section 5 says "An acceptable KDF MUST accept an IKM, L, and
info as inputs." The order of providing them to the KDF is critical
for interoperability. Is there intended to be a defined order in
this document, or is the KDF definition expected to define the
order?
[JG] I believe the KDF definition would need to define this. The KDF API would define what inputs it needs, and a proper KDF implementation would construct them in the order it needs. I don’t think we need to change anything
here. 7. Security Considerations states many SHOULDs involving security
levels being "at least the security level" of another part of KEM.
It would have have been more conventional to specify MUSTs in order
to achieve a consistent security level. I assume there is some
rationale for specifying SHOULDs (e.g., operational considerations
of algorithm deployment), which should be stated.
[JG] There are only 3 SHOULDs in that section. My thoughts on this would be we keep it SHOULD for interoperability. If an encrypted document is sent to the recipient, and the originator did not use the proper security level,
I don’t think the recipient should fail and say sorry, you can’t decrypt your message because the originator didn’t make it strong enough. The damage is already done at that point, the message was sent. Also, the last section points out cryptographic algorithms
become weaker over time, so it is possible a message encrypted in the past, and decrypted in the future may not meet the current security requirements. Thus I think for interoperability it should stay as SHOULD. 8. As quantum-secure KEM algorithms using the
KeyGen()/Encapsulate()/Decapsulate() model are less well-known that
typical public-key encryption algorithms it would be helpful to
provide a reference to at least one algorithm.
[JG] There is the Kyber KEMRI document (https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber/) . We could add that as a reference. Also, we have the
ECDH-KEM document (https://datatracker.ietf.org/doc/draft-ounsworth-lamps-cms-dhkem/which ) could also be used. However, we wouldn’t want to hold up this document to wait
for those. We could just mention it in the introduction “In recent years, cryptographers have be specifying Key Encapsulation Mechanism (KEM) algorithms (for example ML-DSA), including quantum-secure KEM algorithms. The trouble is finding a stable reference.
Perhaps we could point to the NIST competition list of KEM’s? Thanks for your great comments!
John Gray on behalf of the authors group,
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
