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

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Apr 2017 12:30:13 -0400

Hi,

Please find my comments regarding the draft. This is mostly nits and minor
changes and I believe that the next version will be ready to be sent to the
IESG. Any concerned on this draft shoudl be raised before the last call
ends.

Yours,

Daniel

1) nits tool
the nits tools returns the following additional error:

== The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.

2) section 2.1 defining KEK

OLD:
To generate a key-encryption key, generates one or more KM blocks,

NEW:
To generate a key-encryption key (KEK), KDF generates one or more KM blocks,

3) section 2.2 defining HKDF

OLD:
The HKDF key derivation function is a robust construct based on a one-way
hash function described in RFC 5869 [HKDF].

NEW:
The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a
robust construct based on a one-way hash function described in RFC 5869
[HKDF].

4) IANA section:

* Wouldn't it be appropriated to mention RFC7107 section 3.3 and section
3.6 for each allocation.
* I have been recommended to ask to add the IANA link hosting the
registries as an informational reference. In that case, that would be the
following one:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3
* The presentation in the IANA section differs from  the one of RFC7107
which uses a table with Decimal , Description, Reference rather than using
the OID presentation.
* I am wondering whether the current draft does not update RFC7107, in
which case it should be mentioned in the header, abstract and introduction.
What do you think ?

On Wed, Mar 29, 2017 at 2:03 PM, Jim Schaad <[email-masked]> wrote:

>
>
> > -----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.
> >
> > 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.
>
> wfm
>
> >
> > > 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].
>
> wfm
>
> Jim
>
> >
> > Thanks for your review.
> >
> > Russ
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2017 11:02:57 -0400

Daniel:

Thanks for the review.

> == The "Author's Address" (or "Authors' Addresses") section title is

Fixed.

> To generate a key-encryption key (KEK), KDF generates one or more KM blocks,

Okay.  I made that change.

> The HKDF key derivation function is a robust construct based on a one-way hash function described in RFC 5869 [HKDF].
> 
> NEW:
> The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a robust construct based on a one-way hash function described in RFC 5869 [HKDF].

Okay.  I made that change.

> 4) IANA section: 
> 
> * Wouldn't it be appropriated to mention RFC7107 section 3.3 and section 3.6 for each allocation. 

RFC 7107 created the registries.  I do not see any reason to point to that document for the assignment in the registries.

> * I have been recommended to ask to add the IANA link hosting the registries as an informational reference. In that case, that would be the following one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 <http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3>

Okay.  I handed a reference for the module arc and a reference for the algorithm arc.

> * The presentation in the IANA section differs from  the one of RFC7107 which uses a table with Decimal , Description, Reference rather than using the OID presentation.

I used the decimal presentation because that is used in the header of the registry by IANA.

> * I am wondering whether the current draft does not update RFC7107, in which case it should be mentioned in the header, abstract and introduction. What do you think ? 

No.  RFC 7107 established the registry.  It does not need to be updated for every assignment that takes place in those registries.

Russ

---

From: Daniel Migault <[email-masked]>
Date: Mon, 10 Apr 2017 15:06:54 +0000

Thanks for the registries clarification. One more question, are you aware of any implementation of the drafts?
Yours,
Daniel

From: Russ Housley [mailto:[email-masked]]
Sent: Monday, April 10, 2017 11:03 AM
To: Daniel Migault <[email-masked]>
Cc: Jim Schaad <[email-masked]>; curdle <[email-masked]>
Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02

Daniel:

Thanks for the review.

1) nits tool

Fixed.

OLD:

OLD:

4) IANA section:

* I have been recommended to ask to add the IANA link hosting the registries as an informational reference. In that case, that would be the following one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2017 11:16:12 -0400

I have had one person talk to me about implementation, but I do not know if they have started coding yet or not.

Russ

> On Apr 10, 2017, at 11:06 AM, Daniel Migault <[email-masked]> wrote:
> 
> From: Russ Housley [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> Cc: Jim Schaad <[email-masked] <mailto:[email-masked]>>; curdle <[email-masked] <mailto:[email-masked]>>