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

[Eric Rescorla <[e-mail]>]

I apologize but I just took a look at the language around invalid points. I
would suggest
you use the same language as TLS here:

   For X25519 and X448, implementations SHOULD use the approach
   specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748].  If implementers use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].

LMK what you think.

Best,
-Ekr


On Wed, May 10, 2017 at 6:50 AM, Russ Housley <[e-mail]> wrote:

> Yes, that works for me.  I’ll post an updated I-D later today.
>
> Russ
>
>
> On May 9, 2017, at 7:59 PM, Eric Rescorla <[e-mail]> wrote:
>
> 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
>>
>>
>>
>
>