Re: [Curdle] Éric Vyncke's No Objection on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)

mbaushke ietf <mbaushke.ietf@gmail.com> Thu, 08 July 2021 21:24 UTC

Return-Path: <mbaushke.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38C53A1E56; Thu, 8 Jul 2021 14:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmDbQBBNFzGB; Thu, 8 Jul 2021 14:24:33 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00C53A1E55; Thu, 8 Jul 2021 14:24:32 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id q2so9929688iot.11; Thu, 08 Jul 2021 14:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=MlwVPat/CWyKvfsEKcXW3SDkRTMtBL6mpa0r5Bvg9JU=; b=TYm5uhVSQee+OduJSuXKNgtExj4y0LJE7qFnluQaKLXDMfINZT2bA5NsW+7388t7rM qOG2XW3E69QqfMaGUfJoblSBFuJUqtcZgudfH/6V6rb2Sl+/FjUY/knIJSoggFNJVCCg FB0nNSmzBON/CMgLvFnhHnstPckIWhxzxlahhAA6MCKwzT/F5HdoOV4QprfLARUdV1+7 yRKMmhEf0AcdiVINNuZOmmvH7NjwPluXF7ZvJkfsrKLf2QDGa/jBQSPkwJfVxLQSHVPA U83K3Du+qtFdnroT+Fl//pYKnLuiP83A5RVUcfl5+0cLBb+Qug/F8SEgbG/c5kt6l0Mh 9KYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MlwVPat/CWyKvfsEKcXW3SDkRTMtBL6mpa0r5Bvg9JU=; b=CDO29bVCA9Pz7l8uzIXdmu/GJi7Tb+HTW3SaxBRF7i95QvE6RPYEBUPPh8U7E9Qbqo LrjGfQ0BbZiS1JXeGCGlAvMbT9BtH8qgJvehSemYHeE5WUIucSGktLeZEyjrGK9KHrBS 1QMs2wzSwKjiVf8+wEhKF1xK/0rt2BnRgFshCYePMx//KlE2Iq5AaiPhyva/IbRu6ldo qMKK2rTq/0ZCHKyVdu8av8RMgXHNSzTo5JtiQVxxn1DBvl+snDnVDbuFssqECJJv918C V+SnbfItgJHu1heLxIxH5H945jvZ761cMWp0uIRd9cMQgoqZq1NV7EwLYwJ9bWRjZOda YEmQ==
X-Gm-Message-State: AOAM530UZpe1pCqgoAEU06El4xknkHBD+l6zfXtuPjXoMsrvJYeTeP1y hKsWw3smuTvAuCNlvqFlknY=
X-Google-Smtp-Source: ABdhPJzRNCohf58sm5Tre8coShtMjlhqvIN8GxaGEpcTl0CV3LGxH5dRiRFuSWnlkS0V7JxwG0Jdkw==
X-Received: by 2002:a6b:d00b:: with SMTP id x11mr9684884ioa.167.1625779470561; Thu, 08 Jul 2021 14:24:30 -0700 (PDT)
Received: from smtpclient.apple ([2601:249:447e:a900:d066:bf98:f984:9a8]) by smtp.gmail.com with ESMTPSA id 15sm1750600ilt.66.2021.07.08.14.24.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jul 2021 14:24:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AEAA3448-007F-451A-A6AF-AFDAE5F1AD95"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: mbaushke ietf <mbaushke.ietf@gmail.com>
In-Reply-To: <162558455853.4830.18286342256260087971@ietfa.amsl.com>
Date: Thu, 08 Jul 2021 14:24:29 -0700
Cc: The IESG <iesg@ietf.org>, draft-ietf-curdle-ssh-kex-sha2@ietf.org, curdle-chairs@ietf.org, curdle@ietf.org, mglt.ietf@gmail.com
Message-Id: <525D06D2-60C7-4E27-BFAB-885CA2D9A8B7@gmail.com>
References: <162558455853.4830.18286342256260087971@ietfa.amsl.com>
To: Éric Vyncke <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/kxM9UzcPl-zCsebSoTfxKmk3EvQ>
Subject: Re: [Curdle] Éric Vyncke's No Objection on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 08 Jul 2021 21:24:38 -0000

Hi Éric,

Note: I have been asked to not upload new revisions of the document by the Gen-ART reviewer, but I will try to address your comments in this message.

My comments are provided in-line below. Look for MDB:

> On Jul 6, 2021, at 8:15 AM, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-curdle-ssh-kex-sha2-19: No Objection
> 
> 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 the work put into this document.
> 
> Special thanks for Daniel Migault' shepherd write-up about the WG process /
> consensus (I only regret that the write-up was not refreshed as it is dated
> January 2018).
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated). I am still hesitating on a block DISCUSS (see section 1) though
> and could revisit my ballot position.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 1.0 --
> "The purpose of this RFC is to recommend" why not simply "This RFC recommends" ?

MDB: I have no objection to this change.

> 
> Should "most SSH implementations" be qualified by a date?

MDB: I am not sure what benefit that would bring.

The protocol already negotiates what algorithms will be used.

If there are no common algorithms to negotiate, then the connection will fail.

> 
> "  This document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by
>   changing the requirement level ("MUST" moving to "SHOULD" or "MAY" or
>   "SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT"
>   or "MUST NOT") of various key exchange mechanisms."
> 
> I was about to raise a blocking DISCUSS on the above text because it is really
> unclear what the updates are. ***I may reconsider my current position to a
> DISCUSS after thinking twice***.
> 

MDB:

The intent of the document is to provide a survey of all of the key exchanges mechanisms that have been written in RFCs and identify those which are to be disallowed (those transitioning to MUST NOT) or deprecated (those transitioning to SHOULD NOT) as well as to try to provide forward guidance of a new Mandatory to Implement key exchange (MUST).

It is my contention that the rest of the document addresses this paragraph.

If there is a better way to summarize what this RFC will do, please feel free to suggest it.

> -- Section 1.2.2 --
> I am not a cryptographer... so I would welcome some references to the group
> numbers (e.g., group14) linked to the MODP group.

MDB:

RFC 4253 points to RFC 3526. In particular, section 3 of RFC 3526 is a 2048-bit MODP prime.

P = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
Q = (p-1)/2
G = 2

> 
> -- Section 3.1.1 --
> The table uses a 'Guidance' column which is weird in a standard track document,
> which is more normative than 'guidance'.

MDB:

This RFC is providing guidance to both implementors of the SSH protocol and administrators who configure an implementation for use in their own environments.

In the case of administrators, only they really know the nature of their compute environment and are able to determine the performance of the systems which need to communicate over SSH.

> 
> -- Section 3.1.3 --
> "less efficient" on which metric ? CPU utilization ? Memory utilization ?
> Security ?

MDB:

Many CPUs implement hardware acceleration for some cryptographic operations. The NISTP curves given in Table 8 are available for reduced use of both CPU and memory on some family of Intel chips. To the best of my knowledge, the ecdh-sha2-* family of OIDs and the ecmqv-sha2 are always slow and power hogs regardless of cryptographic chip being used.

Only the administrator of an SSH implementation will be able to run tests to see how efficient a given key exchanges may be for the hardware being used. So, that phrase was intended to provide a hint that these particular configuration may not be desirable without testing before deployment.

> 
> -- Section 4 --
> What does "reserved" means in the 'RFCxxxx implement' means ? It smells like a
> IANA registry entry.

MDB:

RFCxxxx is intended to be the RFC number for the current draft when published.

IANA has already asked questions about the right way to implement Table 12 in the ssh-parameters-16 table of the existing IANA ssh-parameters document. I believe that Ben Kaduk will be speaking with the IESG for the right way to do this.

> 
> Table 12 has an unusual title "IANA guidance for key exchange method name
> implementations", do we expect IANA to give guidance about crypto resistance?
> The same applies for section 7 (IANA considerations).

MDB:

It is my hope that the draft will become an RFC and that the ssh-parameters-16 table will be updated to provide current guidance as the the usefulness of various key exchanges. Over time, I expect the table to be updated as cryptographic research finds ways to either break or render weak more key exchange algorithms. I hope that SSH implementations are able to be agile enough to allow administrators to disable broken key exchange algorithms as it becomes necessary.

It is my hope that the comments I have provided help in clearing up your concerns.

If you have additional concerns, please let me know.

        Be safe, stay healthy,
        -- Mark