Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 7 Oct 2016 13:32:03 -0400

Orit,

Thanks for the review, making sure the editor see this.

Kathleen

On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
>
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/
> area/gen/trac/wiki/GenArtfaq>.
>
> Document: review of draft-ietf-ipsecme-safecurves-04
> Reviewer: Orit Levin (mailto:[email-masked])
> Review Date: 2016-09-27
> IETF LC End Date: 2016-09-29
> IESG Telechat date: unknown
>
> Summary:
> This draft is basically ready for publication, but has nits that should be
> fixed before publication. The nits are purely editorial, but fixing them
> will improve the document's readability.
>
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using
> Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear
> which one is "that" document.
> Par.2 "free from": Replace with "resilient to".
>
> 2. Curve25519 and Curve448
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL
> follow the steps described in this section."
> Par.1 Replace "are inherited from" with "are compliant with".
> Par.2 Replace "goes as" with "is performed as"
>
> 3. Use and Negotiation in IKEv2
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced
> with TBA1/TBA2 according to the IANA assignment].
> 3.2 Consider replace the first sentence with
> "Receiving and handling of incompatible point formats MUST comply with [or
> MUST follow] considerations/procedures described in section 5 of [RFC7748]."
>
> 4. Security Considerations
> Par.1 Replace the paragraph text to
> "For high-performance constant-time implementations, it is RECOMMENDED to
> use Curve25519 and Curve448 which were designed for this purpose.
> Implementers MUST/SHOULD NOT attempt to improve performance by reusing
> supposedly ephemeral key pair across multiple key exchanges [because ...]."
> Par.3 In " ... the process used to pick these curves..." replace "these"
> with the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can
> be done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are
> generated in a fully verifiable way".
>
> 6. Acknowledgements
> Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike".
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in
> RFC 7748".
>
> Thank you,
> Orit.
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Oct 2016 22:37:34 +0300

Thanks for that.

For some reason gmail sent this to the spam folder.

Yoav

> On 7 Oct 2016, at 20:32, Kathleen Moriarty <[email-masked]> wrote:
> 
> Orit,
> 
> On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin <[email-masked] <mailto:[email-masked]>> wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> 
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.
> 
> Reviewer: Orit Levin (mailto:[email-masked] <mailto:[email-masked]>)
> Review Date: 2016-09-27
> This draft is basically ready for publication, but has nits that should be fixed before publication. The nits are purely editorial, but fixing them will improve the document's readability.
> 
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear which one is "that" document.
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL follow the steps described in this section."
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced with TBA1/TBA2 according to the IANA assignment].
> "Receiving and handling of incompatible point formats MUST comply with [or MUST follow] considerations/procedures described in section 5 of [RFC7748]."
> 
> "For high-performance constant-time implementations, it is RECOMMENDED to use Curve25519 and Curve448 which were designed for this purpose. Implementers MUST/SHOULD NOT attempt to improve performance by reusing supposedly ephemeral key pair across multiple key exchanges [because ...]."
> Par.3 In " ... the process used to pick these curves..." replace "these" with the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can be done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are generated in a fully verifiable way".
> 
> 6. Acknowledgements
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in RFC 7748".
> 
> Thank you,
> Orit.
> 
> 
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Oct 2016 22:46:19 +0300

Hi, Orit.

I accepted most of your suggestions with a few exceptions below:

> On 28 Sep 2016, at 0:30, Orit Levin <[email-masked]> wrote:
> 
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 

I have left this as is. This worked for me in the past. I will make sure these were replaced during AUTH48.

> "Receiving and handling of incompatible point formats MUST comply with [or MUST follow] considerations/procedures described in section 5 of [RFC7748].”

I ended up with this:
3.2.  Recipient Tests

   Receiving and handling of incompatible point formats MUST follow the
   considerations described in section 5 of [RFC7748].  In particular,
   receiving entities MUST mask the most-significant bit in the final
   byte for X25519 (but not X448), and implementations MUST accept non-
   canonical values.

> "For high-performance constant-time implementations, it is RECOMMENDED to use Curve25519 and Curve448 which were designed for this purpose. Implementers MUST/SHOULD NOT attempt to improve performance by reusing supposedly ephemeral key pair across multiple key exchanges [because ...].”

Your suggested text says that reusing ephemeral keys is a bad thing. Reading over the original text I can see that it could be interpreted like that. This was not our intention. Reusing ephemeral keys is OK. You MUST use a constant-time implementation because otherwise each use of the same ephemeral key may leak a few bits. So if you are reusing the keys, it is especially important to use constant-time implementations, whereas if you only used each key once, it would be kind-of OK to use any implementation.  I’ve reworded the paragraph as follows:

   Curve25519 and Curve448 are designed to facilitate the production of
   high-performance constant-time implementations.  Implementors are
   encouraged to use a constant-time implementation of the functions.
   This point is of crucial importance especially if the implementation
   chooses to reuse its ephemeral key pair in many key exchanges for
   performance reasons.

---

From: Orit Levin <[email-masked]>
Date: Tue, 11 Oct 2016 20:02:29 +0000

Thanks, Yoav!
This addresses all my comments.
Best,
Orit.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, October 11, 2016 12:46 PM
To: Orit Levin <[email-masked]>
Cc: [email-masked]; General Area Review Team <[email-masked]>
Subject: Re: Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit.

I accepted most of your suggestions with a few exceptions below:

> Reviewer: Orit Levin (mailto:[email-masked]) Review Date: 
> 2016-09-27 IETF LC End Date: 2016-09-29 IESG Telechat date: unknown
> 
> Summary:

> 3.2 Consider replace the first sentence with "Receiving and handling 
> of incompatible point formats MUST comply with [or MUST follow] considerations/procedures described in section 5 of [RFC7748].”

I ended up with this:
3.2.  Recipient Tests

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Oct 2016 10:41:25 +0300

Orit & Yoav, thanks much for the review and edits. I have balloted no-obj for this document for the tonight’s IESG telechat.

Jari