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

-----Original Message-----
From: Yoav Nir [mailto:ynir.i...@gmail.com] 
Sent: Tuesday, October 11, 2016 12:46 PM
To: Orit Levin <or...@microsoft.com>
Cc: draft-ietf-ipsecme-safecurves....@ietf.org; General Area Review Team 
<gen-...@ietf.org>
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:

> On 28 Sep 2016, at 0:30, Orit Levin <or...@microsoft.com> 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:or...@microsoft.com) 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].

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

> 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

   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.

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

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.


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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to