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

[Eric Rescorla <[e-mail]>]

On Tue, May 9, 2017 at 1:25 PM, Russ Housley <[e-mail]> wrote:

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

Is this actually possible? The KDF is basically a PRF, so there is some
chance that 0*128 and 1*128 produce the same output.

-Ekr

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