[Curdle] Roman Danyliw's Yes on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 14 July 2021 01:51 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 2656C3A1068; Tue, 13 Jul 2021 18:51:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-ssh-kex-sha2@ietf.org, curdle-chairs@ietf.org, curdle@ietf.org, mglt.ietf@gmail.com, mglt.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <162622751560.27606.16840437035448639983@ietfa.amsl.com>
Date: Tue, 13 Jul 2021 18:51:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/5tphCL1HUvLhGth8RqAtKJg15CU>
Subject: [Curdle] Roman Danyliw's Yes on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)
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: Wed, 14 Jul 2021 01:51:56 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-curdle-ssh-kex-sha2-19: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this helpful, prescriptive guidance.

Thank you to Mališa Vučinić for the multiple SECDIR reviews.

** Table 1, 2, 4, 5.  Cite the basis of the estimated security strengths.  A
few pointers to jump start this process:

-- Table 1: NIST 800-57Part1R5, Section 5.6.1.1
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)

-- Table 2: NIST 800-107r1 Section 4
(https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf);
 and also note that this security strength is collision resistance

-- Table 3: RFC7748 for Curve25519 and Curve448; NIST curves is ??

-- Table 5: NIST 800-57Part1R5, Section 5.6.1.1
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)

** Section 1.1.  In the spirit of inclusive language s/man in the middle/on
path attacker/

** Section 1.1.
It is suggested that the minimum secure hashing function that should
   be used for key exchange methods is SHA2-256

After the previous sentence just went to the effort of defining the security
strength of the SHA-* algorithms by bits, is there a reason the minimum
strength baseline is framed as an algorithm name rather than a number of bits?

** Section 3.4.  This section notes that some legacy situations would find
group14 useful.  Could you elaborate on that situation?

==[ Editorial
** Editorial.  Be consistent with the naming of algorithms with case and
hyphenation.  For example:

-- Section 1.  s/sha1, sha256, sha384, and sha512/SHA-1, SHA-256, SHA-384, and
SHA-512/ -- Section 1.2.2.  s/sha256/SHA-256/ -- Section 1.2.2.
s/aes128/AES-128/ -- Section 1.2.2. s/aes192/AES-192/

(There are likely more instances than those named above)

** Editorial.  Be consistent on either SHA2-256 or SHA-256

** Section 1.1. Typo. /is is/it is/

** Section 1.2.2. s/Cipher/cipher/

** Section 3.2.1.  Editorial.  s/4K/4000/

** Section 3.4.  Typo. s/key exchanges methods/key exchange methods/