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

[Jim Schaad <[e-mail]>]

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

 

 

From: Russ Housley <[e-mail]> 
Sent: Wednesday, November 28, 2018 11:57 AM
To: Jim Schaad <[e-mail]>
Cc: SPASM <[e-mail]>
Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 

 

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 <[e-mail] <mailto:[e-mail]> > wrote:

 

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

 

 

From: Russ Housley < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, November 28, 2018 11:25 AM
To: Jim Schaad < <mailto:[e-mail]> [e-mail]>
Cc: SPASM < <mailto:[e-mail]> [e-mail]>
Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 

 

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 < <mailto:[e-mail]> [e-mail]> 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 < <mailto:[e-mail]> [e-mail]> 
Sent: Tuesday, November 27, 2018 12:22 PM
To: Jim Schaad < <mailto:[e-mail]> [e-mail]>
Cc: SPASM < <mailto:[e-mail]> [e-mail]>
Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 

 

Jim:

 

* I am missing the discussion about what the KDK length is going to be for a

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