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

[Russ Housley <[e-mail]>]

Ben:

I responded to the DISCUSS part of this ballot position last week.  This note responds to the very thoughtful non-blocking COMMENT portion of your ballot position.

> ----------------------------------------------------------------------
> 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?

Some of this is covered in [RFC5652] and [RFC5083].  So, I suggest:

   The security considerations in related to the CMS enveloped-data
   content type in [RFC5652] and the security considerations related to
   the CMS authenticated-enveloped-data content type in [RFC5083]
   continue to apply.

As you indicate, some more of this is already covered by existing text:

   When using a PSK with a key transport or a key agreement algorithm, a
   key-encryption key is produced to encrypt the content-encryption key
   or content-authenticated-encryption key.  If the key-encryption
   algorithm is different than the algorithm used to protect the
   content, then the effective security is determined by the weaker of
   the two algorithms.  If, for example, content is encrypted with
   256-bit AES, and the key is wrapped with 128-bit AES, then at most
   128 bits of protection is provided.  Implementers must ensure that
   the key-encryption algorithm is as strong or stronger than the
   content-encryption algorithm or content-authenticated-encryption
   algorithm.

I suggest we also add some advice about KDF algorithms:

   The selection of the key-derivation function imposes an upper bound
   on the strength of the resulting key-encryption key.  The strength of
   the selected key-derivation function should be at least as strong as
   the key-encryption algorithm that is selected.  NIST SP 800-56C
   Revision 1 [NIST2018] offers advice on the security strength of
   several popular key-derivation functions.

> 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?

It is best if each PSK has a unique identifier; however, if a recipient has more than one PSK with the same identifier, the recipient can try each of them in turn.  I will add that to the end of that paragraph.

> 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.

Okay.  I suggest:

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

> 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.

This applies to KDFs that are built on encryption algorithms too.  I suggest:

   Many key derivation functions (KDFs) internally employ a one-way hash
   function.  When this is the case, the hash function that is used is
   indirectly indicated by the KeyDerivationAlgorithmIdentifier.  HKDF
   [RFC5869] is one example of a KDF that makes use of a hash function.

   Other KDFs internally employ an encryption algorithm.  When this is
   the case, the encryption that is used is indirectly indicated by the
   KeyDerivationAlgorithmIdentifier.  For example, AES-128-CMAC can be
   used for randomness extraction in a KDF as described in [NIST2018].

> (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) }

5 = b'0101'
10 = b'1010'

Just so more bits change on the input to the KDF.

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

Yes, this is redundant.  The length is input as part of the OCTET STRING encoding and as an INTEGER.  Joim Schaad pointed this out a long time ago.  It is an artifact of a change that was made between -00 and -01 of this document.

> 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.

I suggest that the key-encryption key and the KDF be moved to their own paragraph:

   Implementations of the key derivation function must compute the
   entire result, which in this specification is a key-encryption key,
   before outputting any portion of the result.  The resulting key-
   encryption key must be protected.  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.  Note that there are two key-encryption keys when a PSK with
   a key agreement algorithm is used, with similar consequence for the
   compromise of either one of these keys.

>   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"?

Sure.  I'll add "inherently".

>   Implementers should be aware that cryptographic algorithms become
>   weaker with time.  As new cryptoanalysis techniques are developed and
> 
> nit: "cryptanalysis"

Good catch.  I read past that many, many times.

> 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.

I think that the correlation of key transport public identifiers and key agreement public keys would have similar consequences.

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

RFC 5911 is not needed.

RFC 5912 and RFC 6268 are both in the downref registry, so no further process is needed to normatively reference them.

> 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)

I suggest:

   The pre-shared key known to Alice and Bob, in hexadecimal:

Russ