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

[Russ Housley <[e-mail]>]

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]> 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 <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, November 28, 2018 11:25 AM
> To: Jim Schaad <[e-mail] <mailto:[e-mail]>>
> Cc: SPASM <[e-mail] <mailto:[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 <[e-mail] <mailto:[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 <[e-mail] <mailto:[e-mail]>> 
>> Sent: Tuesday, November 27, 2018 12:22 PM
>> To: Jim Schaad <[e-mail] <mailto:[e-mail]>>
>> Cc: SPASM <[e-mail] <mailto:[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