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

[Russ Housley <[e-mail]>]

Jim:

Thanks for reading so carefully.

>>> 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.
> 
> Yeah - no
> 
> s/if the existing syntax the does not/if the existing syntax does not/

Indeed.  Fixed.

>>> 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.
> 
> Ok
> 
>> 
>>> 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). ...
> 
> Ok
> 
>> 
>>> 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.
> 
> Ok
> 
>> 
>>> 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:
> 
> Ok
> 
>>> 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.
> 
> No it does not.  I was referring to the fact that there are no restrictions
> being placed on the KT or KA algorithm.  Specifically that any currently
> defined or future defined algorithm can be used with this process.

I see.  I added:

   ...  No restrictions are imposed on the key transport or key
   agreement public-key algorithms, which means that any key
   transport or key agreement algorithm can be used, including
   algorithms that are specified in the future. ...

>>> 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.
> 
> It does not make it any easier to deploy here than it did in the case of
> distributing a KEK key already.  I have the vaguest of feelings that this
> specific set of properties was originally requested by the US military so
> they had some type of infrastructure that was in place for this purpose.  It
> may have been some type of KDF that was being run but I don't think that was
> ever defined.  Such a thing may also be useful I this case as well.  However
> I was looking more a consistency than having a way to do this type of
> deployment.
> 
>> 
>>> 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].
> 
> The ender uses their own private key, the recipient's public key and a KDF
> to produce the key derivation key.
> A second key KDF is then used to mix the PSK and the key derivation key to
> produce the KEK.
> 
> How long is the key derivation key supposed to be?  In the case of key
> transport that key can be of any size, although it should have a minimum
> length (size of the CEK?), the maximum value can be up to the size of the
> key minus the padding structure being used.
> 
> I don't believe that we currently have anything that says how long the key
> derivation key is going to be.  Does this need to be parametrized or should
> it be "fixed".  The size of the CEK is not a good answer as my code will not
> have looked at the content encoding algorithm when processing this and thus
> would not know the value.  The size of the key wrap algorithm might be
> reasonable length to default to.
> 
>> 
>>> 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".
> 
> I am not sure that I am seeing a reason to have the context string be
> included here.   I don't have any feelings either way.

When key transport is used, the key-derivation key is made up sole by the sender.  So, I was thinking that the context will yield different key-encryption key, even if a silly implementation uses the output of a key agreement operation as the key-derivation key in a subsequent ket transport operation.  I guess it is like your paranoia about the key lengths below.  I came up with a way to address this concern with a single byte and handle your paranoia too.  See below.

> I would not want to just concatenate the two secret values together without
> some type of length/separation existing just due to paranoia. 

Okay.  Since we are talking about the CMS, I think a simple ASN.1 structure similar to the one we used in RFC 2631 is appropriate.  If the length values are included in the info, we can stick with simple concatenation:

CMSORIforPSKOtherInfo ::= SEQUENCE {
  keyMgmtAlgType ENUMERATED {
    keyTrans        (5),
    keyAgree        (10) }
  kekOID          OBJECT IDENTIFIER,
  pskLength       INTEGER (1..MAX),
  kdkLength       INTEGER (1..MAX) }

Russ