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

[Jim Schaad <[e-mail]>]

See inline.

 

From: Curdle [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Tuesday, May 9, 2017 9:04 AM
To: Eric Rescorla <[e-mail]>
Cc: curdle <[e-mail]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

 

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.

 

[JLS] As I have stated in the past – I am with EKR on this.



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



Jim

 

> S 9.
> This section is kinda diffident about whether the sender's
> ephemeral is truly ephemeral. Is this a MUST? If so, please
> say so.

Section 2 already explains that the originator uses an ephemeral key pair.

 

Yes, but it doesn't have any normative language (see above on this topic).

 

I see.  I’ll reword the text in Section 2 to use MUST.

 

How about:

 

   The originator MUST use an ephemeral public/private key pair that is

   generated on the same elliptic curve as the public key of the

   recipient.  The ephemeral key pair MUST be used for a single CMS

   protected content type, and then it MUST be discarded.  The

   originator obtains the recipient's static public key from the

   recipient's certificate [PROFILE].

 





> S 3.
> It would be easier to put this above the key derivation stage.

I followed the outline used in other specifications.  I figures that the implementers were fine with the previous outline.

> Please provide some sort of reference or cross-reference for
> “kari"

The kari is defined in [CMS] as one of the choices in RecipientInfo.  I think that is clear from the sentence.

 

Yeah, I didn't find it super-clear. How about quoting it.

 

Okay.  I suggest:

 

   The enveloped-data content type is ASN.1 encoded using the

   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be

   populated as described in Section 6 of [CMS].  The RecipientInfo

   choice is described in Section 6.2 of [CMS], and repeated here for

   convenience.

 

      RecipientInfo ::= CHOICE {

        ktri KeyTransRecipientInfo,

        kari [1] KeyAgreeRecipientInfo,

        kekri [2] KEKRecipientInfo,

        pwri [3] PasswordRecipientinfo,

        ori [4] OtherRecipientInfo }

 

   For the recipients that use X25519 or X448 the RecipientInfo kari

   choice MUST be used.

 

Russ