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

[Benjamin Kaduk <[e-mail]>]

On Wed, Aug 21, 2019 at 04:02:51PM -0400, Russ Housley wrote:
> 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.

That all sounds good; thanks.

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

Works for me.

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

Sure.

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

Okay.

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

Thanks.

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

Thanks for thinking about it; that's reasonable.

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

Thanks!

-Ben