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

From: Jim Schaad <[email-masked]>
Date: Fri, 9 Nov 2018 14:05:22 +0700

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

Section 1: Needs to be re-worded "if current syntax the does not
accommodated them."
  
Section 1: Needs to be re-worded: " by mixing with a strong PSK with the
output"

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.

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

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.

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?

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.

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?

Jim

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Nov 2018 06:24:04 -0500

Jim:

Thanks for the careful review.

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

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

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

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

> two sentences forward would be useful.  Not talking about generating the

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.

> 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

> towards the underlying key management technique.

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

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

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

> 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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 15 Nov 2018 04:44:36 -0800

> -----Original Message-----
> From: Russ Housley <[email-masked]>
> Sent: Thursday, November 15, 2018 3:24 AM
> To: Jim Schaad <[email-masked]>
> Cc: SPASM <[email-masked]>
> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00
> 
> Jim:
> 

Yeah - no

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

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

Ok

> > Perhaps a simple discussion on how what happens is that an additional
> > key wrap is inserted using ...
> 
> I suggest:
> 

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

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 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.
>       OriginatorIdentifierOrKey type is described in Section 6.2.2 of

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.

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

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

Jim

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Nov 2018 23:05:59 -0500

Jim:

Thanks for reading so carefully.

> s/if the existing syntax the does not/if the existing syntax does not/

Indeed.  Fixed.

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

>> 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
>>> am not completely clear that this is the DH pairwise key or something else.
>> 
>> I suggest:
>> 
>> I needs to add text.  In short, I see the secret input the the KDF simply being

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.

> 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

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Nov 2018 11:47:31 -0500

Jim:

Thanks for the careful review.  I just posted -01 to resolve your comments.

The biggest change is the addition of Section 5 on key derivation.

Russ

> On Nov 9, 2018, at 2:05 AM, Jim Schaad <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 19 Nov 2018 14:44:49 -0800

Reading the document:

* Spencer complained about the fact that I was using the term quantum
resistant in the COSE re-charter effort rather than something like
"resistant to quantum computer attacks" you may want to pre-empt this.

* Section 5 - did you really mean to use 'inout' here?

* I am missing the discussion about what the KDK length is going to be for a
key agreement algorithm.   Am I just blind?

Jim

> Sent: Monday, November 19, 2018 8:48 AM
else.

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Nov 2018 18:34:50 -0500

> * Section 5 - did you really mean to use 'inout' here?

Typo: input

> key agreement algorithm.   Am I just blind?

In Section 4:

      kdfAlgorithm identifies the key-derivation algorithm, and any
      associated parameters, used by the sender to mix the pairwise key
      and the PSK.  The pairwise key input to the key-derivation
      algorithm MUST be the same length as the key-encryption key that
      will be the output by the key-derivation algorithm.  The
      KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of
      [RFC5652].

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Nov 2018 15:21:45 -0500

> key agreement algorithm.   Am I just blind?

I have been playing with a toy implementation to make sure that I have sorted out all of the issues, and I think that the key agreement needs some fine tuning, not so much in what is actually going on, but more in the way that it is explained.

I think this processing description will make more sense, and it will encourage the intended code reuse...

   1. The content-encryption key is generated at random.

   2. The pairwise key-encryption key is established for each recipient.
        The recipient's public key and the sender's private key are used
        to produce a pairwise symmetric key-encryption key, called KEK1.

   3.  The key derivation function (KDF) is used to mix the pre-shared
         key (PSK) and KEK1, and the result is called KEK2.

   4. The KEK2 is used to encrypt the content-encryption key.

KEK1 is not actually used to encrypt anything, but it allows existing DH and ECDH implementations to used without any modification.

I think this also makes it very clear why KEK1 and KEK2 ought to be the same size.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Nov 2018 10:32:08 -0800

I don't know if this is more clear or not.

I am not sure that I agree that this demonstrates why KEK1 and KEK2 ought to
be the same length, to me it only shows why len(KEK1) >= len(KEK2) is a
required factor.  

I don't care enough to say you should change things however.

Jim

Sent: Tuesday, November 27, 2018 12:22 PM

Jim:

I have been playing with a toy implementation to make sure that I have
sorted out all of the issues, and I think that the key agreement needs some
fine tuning, not so much in what is actually going on, but more in the way
that it is explained.

I think this processing description will make more sense, and it will
encourage the intended code reuse...

KEK1 is not actually used to encrypt anything, but it allows existing DH and
ECDH implementations to used without any modification.

I think this also makes it very clear why KEK1 and KEK2 ought to be the same
size.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Nov 2018 14:25:06 -0500

Jim:

I was saying that KEK1 and KEK2 would use the same AlgorithmIdentifier value in any KDF that was used.  For example, KEK1 might come from ECDH with the X9.63 KDF, and then KEK2 would come from the HKDF as described in the I-D.  Both KDFs require an AlgorithmIdentifier as an input.

Russ

> On Nov 28, 2018, at 1:32 PM, Jim Schaad <[email-masked]> wrote:
> 
> I don’t know if this is more clear or not.
>  
> I am not sure that I agree that this demonstrates why KEK1 and KEK2 ought to be the same length, to me it only shows why len(KEK1) >= len(KEK2) is a required factor.  
>  
> I don’t care enough to say you should change things however.
>  
> Jim
>  
>  
> From: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> Cc: SPASM <[email-masked] <mailto:[email-masked]>>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Nov 2018 11:32:48 -0800

Ahhh yes, I was planning on using the KDF algorithm identifier (assuming it has one) rather than the key wrap algorithm identifier for that step.

If there wasn’t one then I would probably have asked for one.  

Jim

Sent: Wednesday, November 28, 2018 11:25 AM

Jim:

Russ

On Nov 28, 2018, at 1:32 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

From: Russ Housley < <mailto:[email-masked]> [email-masked]> 
Sent: Tuesday, November 27, 2018 12:22 PM
To: Jim Schaad < <mailto:[email-masked]> [email-masked]>
Cc: SPASM < <mailto:[email-masked]> [email-masked]>
Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 

Jim:

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Nov 2018 14:57:01 -0500

That bit of ambiguity is what jumped out at me when I was working with my toy implementation.  I also discovered that the library that I was using did not easily allow additional OIDs in the key agreement.

Russ

> On Nov 28, 2018, at 2:32 PM, Jim Schaad <[email-masked]> wrote:
> 
>> On Nov 28, 2018, at 1:32 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 29 Nov 2018 12:12:35 -0800

While my position is the “more correct” position, I can understand why the library being used might influence your choice here.  In any event which one is being used needs to be stated especially if you are going to re-use the KEK algorithm at this point.

Given that KEK1 is an ephemeral value that is known only to the sender and the specific recipient, I cannot come up to any way that a third party (potentially another mail recipient) can remove or insert the PSK KDF step.  This would be the major issue that I would have with re-using the same algorithm identifier in both KDF steps.

Jim

Sent: Wednesday, November 28, 2018 11:57 AM

Russ

On Nov 28, 2018, at 2:32 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

Jim:

Russ

On Nov 28, 2018, at 1:32 PM, Jim Schaad < <mailto:[email-masked]> [email-masked]> wrote:

Jim

Jim:

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Nov 2018 15:31:07 -0500

> On Nov 29, 2018, at 3:12 PM, Jim Schaad <[email-masked]> wrote:
> 

I agree, and that is why my original text follows that path.  However, I think we want to embrace the use of existing implementations.  I think this is especially true since this is a short-term solution, where the long term solution is to support the quantum-resistant key management algorithm that comes out of the NIST competition.

> Given that KEK1 is an ephemeral value that is known only to the sender and the specific recipient, I cannot come up to any way that a third party (potentially another mail recipient) can remove or…

Right, KEK1 only gets used in the key derivation of KEK2, and it is only known to the originator and one recipient.

Russ