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

[Russ Housley <[e-mail]>]

> On May 9, 2017, at 1:50 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Tue, May 9, 2017 at 9:03 AM, Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
> I dropped the parts that have been resolved.
> 
>> > TECHNICAL
>> > S 2.
>> >    X25519 is described in Section 6.1 of [CURVES], and X448 is described
>> >    in Section 6.2 of [CURVES].  Since curve25519 and curve448 have
>> >    cofactors of 8 and 4, respectively, an input point of small order
>> >    will eliminate any contribution from the other party’s private key.
>> >    As described in Section 7 of [CURVES], implementations SHOULD detect
>> >    this situation by checking for the all-zero output.
>> >
>> > Why are you not requiring this check? SSH and TLS both do.
>> 
>> RFC 7748 [CURVES] says:
>> 
>>    Protocol designers using Diffie-Hellman over the curves defined in
>>    this document must not assume "contributory behaviour".  Specially,
>>    contributory behaviour means that both parties' private keys
>>    contribute to the resulting shared key.  Since curve25519 and
>>    curve448 have cofactors of 8 and 4 (respectively), an input point of
>>    small order will eliminate any contribution from the other party's
>>    private key.  This situation can be detected by checking for the all-
>>    zero output, which implementations MAY do, as specified in Section 6.
>>    However, a large number of existing implementations do not do this.
>> 
>> We upgraded the MAY to a SHOULD.  We are being told that some implementations will not perform this check, so it seemed wrong to go all the way to MUST.
>> 
>> I'd like to push on this some, because I'm having trouble seeing why different IETF protocols have different needs. When you say "you are being told" is that an S/MIME specific point or merely the the text above?
> 
> The text above, which I gather is about some existing implementations, probably libraries.  I do not know what protocols use those implementations, but if they are libraries they will get used with many different protocols.
> 
> Sure, but other protocols are requiring it and it seems like S/MIME could also do so, in
> the worst case at the point where Z is handed off to S/MIME. 

I suggest:

   X25519 is described in Section 6.1 of [CURVES], and X448 is described
   in Section 6.2 of [CURVES].  As described in Section 7 of [CURVES],
   curve25519 and curve448 have cofactors of 8 and 4, respectively, and
   so an input point of small order will eliminate any contribution from
   the other party's private key.  Conforming implementations MUST check
   for the all-zero output to prevent this situation.


>> >    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?
> 
> Sorry, I was trying to talk it over, but I'm not sure how helpful I am being. It seems like the basic requirement is that it be unique and that if we want to give guidance it should be on the collision probability. Do we believe that 128 bits is enough (I do!), in which case we can just say "if you are generating it randomly, then N bits is enough”

Jim is correct that counters, encrypted counters, linear feedback shift registers, and other techniques will work here too.

Since Section 2 already says that the ephemeral key MUST be used for only one message, 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.

The text already says that there is no security reason for a UKM value that is longer than the KEK.  I think that you are asking for guidance on the minimum size too.  Based on Jim’s point, I’d like to say that it MUST be at least 8 octets.

Russ