[Curdle] Genart last call review of draft-ietf-curdle-ssh-curves-09

Christer Holmberg via Datatracker <noreply@ietf.org> Thu, 22 August 2019 12:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: curdle@ietf.org
Delivered-To: curdle@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2E7120820; Thu, 22 Aug 2019 05:00:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Christer Holmberg via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: curdle@ietf.org, ietf@ietf.org, draft-ietf-curdle-ssh-curves.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Christer Holmberg <christer.holmberg@ericsson.com>
Message-ID: <156647523885.14827.16394888562228822662@ietfa.amsl.com>
Date: Thu, 22 Aug 2019 05:00:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/E5Y-JeGcoDLBpUd5QNqaL1V7RmI>
Subject: [Curdle] Genart last call review of draft-ietf-curdle-ssh-curves-09
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 12:00:39 -0000

Reviewer: Christer Holmberg
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-curdle-ssh-curves-09
Reviewer: Christer Holmberg
Review Date: 2019-08-22
IETF LC End Date: 2019-08-26
IESG Telechat date: Not scheduled for a telechat

Summary:

The document is almost ready for publication. I have no technical issues, but
there are some issues in Section 1 that I'd like to authors to address.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:

General:
---------

QGEN_1:

- The document uses “as discussed in”, “as defined in”, “as described” in
terminology. It might be justified to use different terminology in some cases,
but in general I suggest trying to use consistent terminology.

Section 1:
----------

Q1_1:

The text says:

   ”[RFC5656] describes how elliptic curves are
   integrated in SSH, and this document reuses those protocol messages.”

…and:

   “This document describes how to implement key exchange based on
   Curve25519 and Curve448 [RFC7748] in SSH.”

-       It is unclear to me what “integrated in SSH” means. Does it mean that
RFC 5656 describes the generic procedures for performing SSH key exchanges
using elliptic curves, or does it also cover other things? -       I think the
“this document reuses those protocol messages” sounds a little confusing
because I don’t know what “those protocol message” refers to. Perhaps say
something like “reuses the protocol messages defined in that specification”.

Q1_2:

- I don’t think you should use “we” terminology (“we describe”, “we chose”,
etc..). Please talk about the document, and if you want to refer to a choice
made by the WG please indicate that.

Q1_3:

- Instead of “currently”, I suggest to say something like “at the time of
publication”. Because, the meaning of “currently” changes every second :)

Q1_4:

The text says:

“The Curve448 key exchange method is novel but similar in spirit,”

- I don’t know what this means, since there is now further explanation.

Q1_5:

The text says:

   “This document provide Curve25519 as the preferred choice, but
   suggests that the fall back option Curve448 is implemented to provide
   an hedge against unforeseen analytical advances against Curve25519
   and SHA-256.”

- Is the only reason why one should implement Curve448 that something MAY
happen to Curve25519 in the future?

- Also, is there anything preventing unforeseen analytical advances against
Curve448?