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

[Eric Rescorla <[e-mail]>]

I guess I would focus on the uniqueness of the input, because the output's
uniqueness is largely a function of:

1. Input uniqueness
2. The number of discrete inputs.

So, I think I would say:

"it MUST be selected in a manner that ensures it is unique with high
probability"

-Ekr



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

>
> On May 9, 2017, at 5:16 PM, Eric Rescorla <[e-mail]> wrote:
>
>
> 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.
>
>
> s/ensure/will with very high probability produce/
>
> Russ
>
>
>