[lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-cms-mix-with-psk-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need to have a discussion about the abstract API for a
KEY-DERIVATION instance and how that relates to what we need for a key
combination operation.  In Section 5 we assume that we can use the
HKDF terminology, but that doesn't seem to hold universally for
KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, PBKDF2
(from RFC 3211 that AFAICT introduces keyDerivationalgorithm for CMS) is
specified by RFC 2898 as taking just the input secret (password) and a
salt, with no separate 'info' (and of course the different iteration
count and PRF parameters needed for its construction).  I note (with
chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" for
the HKDF-based KEY-DERIVATION instances but is silent about how one is
supposed to know what to pass for salt/info (the IKM we can perhaps
assume will be obvious).

In short, should we be seeking to define a distinct key combination
operation like KRB-FX-CF2 (RFC6113) rather than trying to repurpose key
derivation?  Some KDFs support this fairly well, but it's not clear to
me that it is a universal property.  For example, the proof in [H2019]
seems to be assuming HKDF but this draft does not (as is clearly seen
from the use of the X9.63 KDF in one of the examples).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Do we need to document the risk of "algorithm mismatch" that is present
because we use separate algorithm identifiers for KDF, key-encryption,
key-agreement, etc. (vs. a "cipher-suite"-like approach that bundles
together a known-good combination)?  In particular, I see we talk about
the key length for content- and key-encryption algorithms, but are there
other constraints that should be applied?

Section 2

                                  The PSK MUST be distributed to the
   sender and all of the recipients by some out-of-band means that does
   not make it vulnerable to the future invention of a large-scale
   quantum computer, and an identifier MUST be assigned to the PSK.

What are the uniqueness/scope requirements for that identifier?

Section 3

      ktris contains one KeyTransRecipientInfo type for each recipient;
      it uses a key transport algorithm to establish the key-derivation
      key.  KeyTransRecipientInfo is described in Section 6.2.1 of
      [RFC5652].

I think we need to be more clear that the 'encryptedKey' member of
KeyTransRecipientInfo contains not the "result of encrypting the
content-encryption key for this recipient" per RFC 5652, but rather the
"result of encrypting the key-derivation key for this recipient".  That
is, to call out how we are deviating from RFC 5652.

Section 5

   Many key derivation functions (KDFs) internally employ a one-way hash
   function.  When this is the case, the hash function that is used is
   identified by the KeyDerivationAlgorithmIdentifier.  HKDF [RFC5869]

(editorial?) This reads as if the KeyDerivationAlgorithmIdentifier is
going to be (e.g.) 2.16.840.1.101.3.4.2.1 for regular SHA-256, which is
presumably not the case.  It sounds more like "indicated by" or
"indicated as part of the semantics of the" would be more appropriate.

(side note) Is there a story behind using 5 and 10 for the ENUMERATED
values?

         CMSORIforPSKOtherInfo ::= SEQUENCE {
           psk                    OCTET STRING,
           keyMgmtAlgType         ENUMERATED {
             keyTrans               (5),
             keyAgree               (10) },
           keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
           pskLength              INTEGER (1..MAX),
           kdkLength              INTEGER (1..MAX) }

If psk is encoded as an OCTET STRING (i.e., including its length), why
do we need a separate pskLength field?

Section 7

   material.  Compromise of the key-encryption key may result in the
   disclosure of all content-encryption keys or content-authenticated-
   encryption keys that were protected with that keying material, which
   in turn may result in the disclosure of the content.

a nit, but for the key-agreement variant we have two things that we call
"key-encryption key"s, so use of the definite article here is
potentially ambiguous.

   This specification does not require that PSK is known only by the
   sender and recipients.  The PSK may be known to a group.  Since
   confidentiality depends on the key transport or key agreement
   algorithm, knowledge of the PSK by other parties does not enable
   eavesdropping.  However, group members can record the traffic of

Would it be appropriate to add either "inherently" (enable
eavesdropping) or "with currently available technology"?

   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptoanalysis techniques are developed and

nit: "cryptanalysis"

Section 8

With respect to "not really making privacy worse", this does seem to
risk exposing that a group of (identified) recipients/participants share
access to a single PSK (identity), which could potentially correlate
them for other sorts of surveillance/attack.

Section 10.2

Don't RFCs 5911, 5912, and 6268 need to be normative since we import
from them in the ASN.1 module?

Section A.1

[I did not attempt to validate the examples.]

   The pre-shared key known to Alice and Bob:
      c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15

(Should we say it's in hex?  Similarly for other non-ASCII-armored
fields, especially the PSK identifier which looks like it is more of a
string than a hex-encoded binary blob)