Subject: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02

From: Jim Schaad <[email-masked]>
Date: Wed, 29 Mar 2017 10:26:32 -0500

Major
1. The reference [CURVE] does not exist in the draft
2.  I would like to see the ZERO check raised from a MAY to a SHOULD.  This
is a concern that needs to be addressed to be sure that the recipient key is
not of small order.  If the sender uses a small group key, then that is
their fault.   Not a hill I would die on.
3.  In section 2 - note that the 32-bit number is encoded in network by
order.  This can be inferred from the example but being explicit is always
good.
4.  Section 6 is incorrect for the X25519 and X448 curves.

Minor:
Section 2 - s/describe/described/

Jim

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Mar 2017 13:40:12 -0400

> 1. The reference [CURVE] does not exist in the draft

s/[CURVE]/[CURVES]

> their fault.   Not a hill I would die on.

I am following the guidance in Section 7 of [CURVES]:

   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.

I am willing to do with SHOULD.  What do others think?

> order.  This can be inferred from the example but being explicit is always

I think this is the text you are talking about:

   To generate a key-encryption key, generates one or more KM blocks, with
   the counter starting at 0x00000001, and incrementing the counter for each
   subsequent KM block until enough material has been generated.  The 32-bit
   counter is represented in network byte order.  The KM blocks are
   concatenated left to right to produce the pairwise key-encryption key,
   KEK:

Let me know if you meant something else.

> 4.  Section 6 is incorrect for the X25519 and X448 curves.

Right.  This needs simple point to draft-ietf-curdle-pkix for the details:

   RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates in
   Internet applications.  A recipient static public key is needed for X25519
   or X448, and the originator obtains that public key from the recipient's
   certificate.  The conventions for carrying X25519 and X448 public keys are
   specified in [ID.curdle-pkix].

> Section 2 - s/describe/described/

Fixed.

Thanks for your review.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 29 Mar 2017 13:03:47 -0500

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2017 12:40 PM
> To: Jim Schaad <[email-masked]>
> Cc: curdle <[email-masked]>
> Subject: Re: Review of draft-ietf-curdle-cms-ecdh-new-curves-02
> 
> Jim:
> 
> > Major
> 
> > 3.  In section 2 - note that the 32-bit number is encoded in network
> > by order.  This can be inferred from the example but being explicit is
> > always good.
> 

wfm

>    specified in [ID.curdle-pkix].

wfm

Jim