Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00

[Russ Housley <[e-mail]>]

Jim:

Thanks for the careful review.

> Abstract:  Needs to be re-worded " if existing syntax the does not
> accommodated them."

I suggest:

   The invention of a large-scale quantum computer would pose a serious
   challenge for the cryptographic algorithms that are widely deployed
   today.  The Cryptographic Message Syntax (CMS) supports key transport
   and key agreement algorithms that could be broken by the invention of
   such a quantum computer.  By storing communications that are
   protected with the CMS today, someone could decrypt them in the
   future when a large-scale quantum computer becomes available.  Once
   quantum-secure key management algorithms are available, the CMS will
   be extended to support the new algorithms, if the existing syntax the
   does not accommodate them.  In the near-term, this document describes
   a mechanism to protect today's communication from the future
   invention of a large-scale quantum computer by mixing the output of
   key transport and key agreement algorithms with a pre-shared key.

> Section 1: Needs to be re-worded "if current syntax the does not
> accommodated them."

I suggest:

   Once quantum-secure key management algorithms are available, the CMS
   will be extended to support them, if the existing syntax the does not
   already accommodate the new algorithms.

> Section 1: Needs to be re-worded: " by mixing with a strong PSK with the
> output"

In suggest:

   In the near-term, this document describes a mechanism to protect
   today's communication from the future invention of a large-scale
   quantum computer by mixing the output of existing key transport and
   key agreement algorithms with a pre-shared key (PSK). ...

> Section 2 -  Which key? "generates the key"  Pushing something from the next
> two sentences forward would be useful.  Not talking about generating the
> ephemeral DH key.

I suggest:

   The CMS enveloped-data content type [RFC5652] and the CMS
   authenticated-enveloped-data content type [RFC5083] support both key
   transport and key agreement public-key algorithms to establish the
   key used to encrypt the content.  In both cases, the sender randomly
   generates the content-encryption key, and then all recipients obtain
   that key.  All recipients use the sender-generated symmetric key for
   decryption.

> Section 2 - you have not introduced the KDK yet and now I am creating one.
> Perhaps a simple discussion on how what happens is that an additional key
> wrap is inserted using ...

I suggest:

   This specification defines two quantum-resistant ways to establish a
   symmetric key-derivation key.  In both cases, the PSK is mixed with
   the key-derivation key to create a quantum-resistant key-encryption
   key.  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.

   The content-encryption key or content-authenticated-encryption key is
   quantum-resistant, and it is established using these steps:

> Section 2 - It would be nice to add a sentence where you say that you are
> introducing two new management techniques to say that they are agnostic
> towards the underlying key management technique.

I am not sure whether the above suggestion resolves this comment or not.

> Section 3 - I am wondering if it would make more sense to use the
> KEKIdentifier structure instead of just having an octet string for the
> PreSharedKeyIdentifier type?

      KEKIdentifier ::= SEQUENCE {
        keyIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

I think you are suggesting that the PreSharedKeyIdentifier would represent a set of keys and that the date and other fields would be used to select among the keys in the set.  I cannot see how that makes it easier to deploy.

> Section 4 - This is twice that I have read this and am unclear what we are
> doing.  The sentence "private key and recipient's public key to generate a
> pairwise key"  From this and from information in my mind I am not completely
> clear that this is the DH pairwise key or something else.

I suggest:

      originator is a CHOICE with three alternatives specifying the
      sender's key agreement public key.  Implementations MUST support
      all three alternatives for specifying the sender's public key.
      The sender uses their own private key and the recipient's public
      key to generate a pairwise symmetric secret value.  A key
      derivation function (KDF) is used to mix the PSK and the pairwise
      symmetric secret value to produce a key-encryption key.  The
      OriginatorIdentifierOrKey type is described in Section 6.2.2 of
      [RFC5652].

> Summary:  Is it your thought that I should be able to implement this
> document as written?  A the moment I do not believe that this is possible.
> Do we need to define how the KDF function operates?

I needs to add text.  In short, I see the secret input the the KDF simply being the concatenation of the PSK and the key-derivation key.  In addition, the context string should be either "KeyTransPSKRecipientInfo" or "KeyAgreePSKRecipientInfo".

Russ