Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

[Jim Schaad <[e-mail]>]

 

 

From: Russ Housley [mailto:[e-mail]] 
Sent: Tuesday, May 9, 2017 1:26 PM
To: Jim Schaad <[e-mail]>; Eric Rescorla <[e-mail]>
Cc: curdle <[e-mail]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

>    The ECC-CMS-SharedInfo entityUInfo field optionally contains
>    additional keying material supplied by the sending agent.  Note that
>    [CMS] requires implementations to accept a KeyAgreeRecipientInfo
>    SEQUENCE that includes the ukm field.  If the ukm field is present,
>    the ukm is placed in the entityUInfo field.  The ukm value need not
>    be longer than the key-encryption key that will be produced by the
>    KDF.
>
> Need not? Please clarify what the purpose is here. It seems like
> it's to generate a unique KEK. In that case, the security bounds
> are what, uniqueness?

I suggest this wording:

   … There is no security benefit to using a ukm value that is
   longer than the key-encryption key that will be produced by
   the KDF.

 

Hmm... I believe that this statement is true, but it also seems to be

incomplete. I may be reasoning about this incorrectly, but it seems

to me that the minimal security requirement is that the UKM be

unique, but that can be achieved with a value much smaller than

the KEK. For instance, it seems like if you have a 256-bit KEK,

then you would still be OK with a randomly-generated 128-bit

UKM. And if we're concerned about random collisions, then the

usefulness bound is actually min(|KEK|, |hash compression function size|).

 

Yes. The umm value needs to be different for each invocation of the KDF, otherwise it does not provide the assurance that different keying material will be produced.  Of course, an implementation will generate the umm value using random number generator, not track the values that are used.  Several years ago, there was a discussion about the size of the ukm needed.  Some people were suggesting crazy large values, and the point was made that anything beyond the SIZEOF(KEK) did not improve security.

 

Are you asking for a sentence saying that the ukm, if present, MUST be at least 128 bits?

 

[JLS] I would disagree that the value has to be random, a counter will work as well.  (An encrypted counter is better.)  I not be happy with a fixed size requirement on this easier.  There is no reason to make such a requirement that I can think of.  A 64-bit counter is just as rational.  It might make more sense to change this statement into something along the lines of 

 

* Any pair of static keys MUST NOT be used more times than the size of the key.  I.e. if 128-bit KEKs may be used, then there is a 2^128 limit on the number of times the key pair can be used.

* The size of the KEK is normally not longer than the length of the resulting KEK as that is the limit of unique values that can be generated in any event.

 

Section 2 already says that the ephemeral key MUST be used for only one message.  Thus, a UKM is not really needed.  However, the CMS requires support for a UKM if the sender include it.  For this reason, the document says how to handle it in the KDF if it is present.

 

You are correct that a counter, encrypted counter, or random value will work, even if the originator uses the same ephemeral key for many messages.  The text does not limit the choices in any way.

 

The text already says that there is no security reason for a UKM value that is longer than the KEK.  I think that EKR is asking for guidance on the minimum size too.

 

[JLS] It’s kind of a stupid thing to do, but the minimum size would be one bit.  Although this is not legal from an ASN.1 standpoint – so the minimum would be one byte. 

 

A single byte with all bits zero and two bytes with all bits zero are different ukm values because of the way that they are used in the ECC-CMS-SharedInfo structure.  Note that this would not be the case if the ukm value was only used as a salt value to HKDF.  I do not see any reason to specify a minimum length of this value.  The only thing that is required is uniqueness, EKR is correct about saying this. 

 

I suggest:

 

   The ECC-CMS-SharedInfo entityUInfo field optionally contains

   additional keying material supplied by the sending agent.  Note that

   [CMS] requires implementations to accept a KeyAgreeRecipientInfo

   SEQUENCE that includes the ukm field.  If the ukm field is present,

   the ukm is placed in the entityUInfo field.  When present, the ukm

   ensures that a different key-encryption key is generated, even when

   the originator ephemeral private key is improperly used more than

   once.  Therefore, if the ukm field is present, it MUST be selected in

   a manner that ensures a unique KDF output; however, there is no

   security benefit to using a ukm value that is longer than the key-

   encryption key that will be produced by the KDF.

 

[JLS] Looks good to me

 

Russ