Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2

"Mark D. Baushke" <mdb@juniper.net> Wed, 10 February 2021 07:44 UTC

Return-Path: <mdb@juniper.net>
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 515AD3A0D9A for <curdle@ietfa.amsl.com>; Tue, 9 Feb 2021 23:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=juniper.net header.b=0dkrreZD; dkim=pass (1024-bit key) header.d=juniper.net header.b=GONhS0Cg
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 fpSgnIuQV5qF for <curdle@ietfa.amsl.com>; Tue, 9 Feb 2021 23:44:09 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA223A0D8A for <curdle@ietf.org>; Tue, 9 Feb 2021 23:44:09 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11A7d24n018481; Tue, 9 Feb 2021 23:44:08 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-transfer-encoding : date : message-id; s=PPS1017; bh=q4MhhQmDdtm5w4Oh/CeUoTdAoHV5mYV4mXMGHIwAq+8=; b=0dkrreZDmcEk4EtL8WP9xf/weKLuvW8pvJ+jwHV7/EI3N780ojGmqfOkAnG7Nl1kq4I1 lYJddjcSjmrhrvo5L6n9ZZJQTj5FCE709kqTy+/TrtphcUkxDk3hZ3J6dbrn8qZSL9Hj TfHxTO+S8nyHhCD93hZNtTGN1moYIb6ekTtzoivxmSGhhTzH5MQRw3USET1gbG0JdiQf 0eRaaXcEszwg11Ndf+wqdlHYODrQgZYmapkerBjsDaU25gU6ocDgQjnHiQ3bikAulviZ yYjey2GA8+z2obwP9M6B525yOnvJOVt12TaPivqkUp5sjL+EADh7NJRjRxmIWCeC2omW Ig==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0b-00273201.pphosted.com with ESMTP id 36m5qh0ffr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Feb 2021 23:44:07 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRFq/F+NwDBzWFiMMTN8+RC5MLNK8XIP6t17H5s6vJkBAjfdv1meLcttceBShrUJwA9uhx9TSobXhg+DV0jRHt5KgJDo7OCgfyw/LPf7nzoha+IKo2OvHfOo7aYF4nkjT98pWfxmCSjHC20wuLj10LOW4/NuJ0ZfgnE8ZeDBJRnf2GFMffry5+JFIRRo0k6PyDFowleQhsENVDhfc9hS5vyjHQkAiIm65CmaEotviWS+2/R+DrrVQv5hoyAmtOPkQ3BjLVEaVBu0/GfUCS/V3Wt4qduF9whY7FQp8AtKLbna27whPMenlh14BerfIW+cRY/BKJshd88kX2POVgIWcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q4MhhQmDdtm5w4Oh/CeUoTdAoHV5mYV4mXMGHIwAq+8=; b=HF5cwPZfIYLBVvQiInID4nZkSQS/8bfFE4sIX7HAbEBhEPN7wRe2zxthu+Txoe7GCuc+w2OgK0foEQKDrkVkJf/FREqkNUJv1Hvvq89jDlCFHaT5fIO8YTdYdXOERoL/s0Q82DalOB6TAZrvFuybLafO5Ts1SL7wcw9X8RKYob6jTQGVAMnS1Ti4TAmUdYFJUs9q3MqjoxAgZF5zGbpnzoJnavDh8BR+SQRSlZ81ZXLZPjaECj8AobiFvBNdUyZQAT0rfBi4iwSzUJ3ta++KzZz4Ku/lH6tsaeOAsOY+XXtdAFi/kZeOZk1wbZQdB6rhOOvwGBkBABTHrDSbVHo7Sg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=mit.edu smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q4MhhQmDdtm5w4Oh/CeUoTdAoHV5mYV4mXMGHIwAq+8=; b=GONhS0CgOL96hC8vSKCoKUu0if+IVMF1DMEqamvsnp/zHQX+7OgE6vsRTANvtJb53XR1px5uTb42ZOxmx+QVoCJy4mblCMv+iZPheNqRqpvGpqoJ5jvSlbEEDy/NM95DeoCng40tnY9Jx8Ts0PvEo3OLQkmB/fq9hYSxI0YIJYg=
Received: from BN9PR03CA0620.namprd03.prod.outlook.com (2603:10b6:408:106::25) by DM5PR05MB2970.namprd05.prod.outlook.com (2603:10b6:3:54::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.10; Wed, 10 Feb 2021 07:44:06 +0000
Received: from BN8NAM12FT040.eop-nam12.prod.protection.outlook.com (2603:10b6:408:106:cafe::c9) by BN9PR03CA0620.outlook.office365.com (2603:10b6:408:106::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Wed, 10 Feb 2021 07:44:06 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by BN8NAM12FT040.mail.protection.outlook.com (10.13.182.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3846.25 via Frontend Transport; Wed, 10 Feb 2021 07:44:05 +0000
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Feb 2021 23:44:05 -0800
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Feb 2021 23:44:04 -0800
Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 9 Feb 2021 23:44:04 -0800
Received: from eng-mail03.juniper.net (eng-mail03.juniper.net [10.108.22.11]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 11A7i3qh021513; Tue, 9 Feb 2021 23:44:03 -0800 (envelope-from mdb@juniper.net)
Received: from eng-mail03 (localhost [127.0.0.1]) by eng-mail03.juniper.net (8.16.1/8.14.9) with ESMTP id 11A7kZ2i016625; Tue, 9 Feb 2021 23:46:35 -0800 (PST) (envelope-from mdb@juniper.net)
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Daniel Migault <mglt.ietf@gmail.com>, curdle <curdle@ietf.org>
In-Reply-To: <20210210022155.GG21@kduck.mit.edu>
References: <CADZyTkkTg0HV5EmxmVX7+Dqu7u7ufhycRtSSM06e=acnWzEj7A@mail.gmail.com> <CADZyTknLG1D2r3tqMGKinfMz7bZQRupLupVE_3gSqjLXkQWEaA@mail.gmail.com> <45081.1612307585@eng-mail03> <20210210022155.GG21@kduck.mit.edu>
Comments: In-reply-to: Benjamin Kaduk <kaduk@mit.edu> message dated "Tue, 09 Feb 2021 18:21:55 -0800."
From: "Mark D. Baushke" <mdb@juniper.net>
X-Phone: +1 408 745-2952 (Office)
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1
X-Face: #8D_6URD2G%vC.hzU<dI&#Y9szHj$'mGtUq&d=rXy^L$-=G_-LmZ^5!Fszk:yXZp$k\nTF? 8Up0!v/%1Q[(d?ES0mQW8dRCXi18gK)luJu)loHk, }4{Vi`yX?p?crF5o:LL{6#eiO:(E:YMxLXULB k|'a*EjN.B&L+[J!PhJ*aX0n:5/
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Feb 2021 23:46:30 -0800
Message-ID: <16624.1612943190@eng-mail03>
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ce10b309-4dff-4815-06f5-08d8cd97a4b8
X-MS-TrafficTypeDiagnostic: DM5PR05MB2970:
X-Microsoft-Antispam-PRVS: <DM5PR05MB2970BEE40ABD3A867CC72792BF8D9@DM5PR05MB2970.namprd05.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: EKT49lYSl6nZQ638UIkSxaadpy+jVrMARU7Wu8DLBl+a0kxv1WaDxAYa+ypfzgxeERu+nWtD1bZEpg/hSPgqzu10x6npXiPUsr4vWZOA6TjbfhwxvtNCFTFJVI9reyszRzJmdbszlN8UlelNlg9zdgSI2euKV9ChmCkcKN084eoFiYBRqHpIRGrJGPBxOWM8njOvcL2mZ8QAPniHq98wTH7tympiaAKTxrl7uzid908K+aiwmqyEZdWEf4TjG0xbcyGqCy9y31OK/hH3SgxbLmRftQAX2q8XVEZR3SdaztMXlObYwMHPabhqCsFvhSx1CnaGpJEoEEOHD8zHOn7OwnR0ldxJDncJvlUAuUAnnmMy+vuGP5vUA5j57/oxFmcvBxjB2Gl25wUo6QbEXJKhZpVedcyjrEZC2qf5cem/M51fcGx85Q/WiY4seavFp2NQJbnyQl5WfMvtJuXByjh+sZv6TgMUNBBQz8HVCtVhm1c+O72dp79wZuj1GGIuZic6qhbqz+SlV/4KdcwKj4T1BJwFrnxP2FJg9iW1Md35IhejIYZSow34F4z4nySEpbrpeVTnlapC227Qw5NvWFb21aCC1ZlG+Q0HyGSsD9QRMGPhUeLWBwkTECfTI4LP0JvR163+NGAcxgqKekC5NPh9ul8bdjGSozBp2e9wu5woVDjT3MF+3AtJhGDWOtrshiLqUju5MY1LjKpKJ10m6iaWrw==
X-Forefront-Antispam-Report: CIP:66.129.239.12; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:P-EXFEND-EQX-01.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(39860400002)(376002)(36840700001)(46966006)(33716001)(86362001)(5660300002)(26005)(478600001)(36860700001)(336012)(7126003)(186003)(426003)(82310400003)(6916009)(9686003)(8936002)(70586007)(316002)(70206006)(54906003)(4326008)(6666004)(2906002)(8676002)(47076005)(82740400003)(356005)(83380400001)(81166007)(36900700001)(62816006); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2021 07:44:05.8625 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ce10b309-4dff-4815-06f5-08d8cd97a4b8
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[P-EXFEND-EQX-01.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT040.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2970
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-10_02:2021-02-09, 2021-02-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 phishscore=0 spamscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102100078
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/4QmIWO7zxZBzkUA0B2a_47pnwBo>
Subject: Re: [Curdle] WGLC draft-ietf-curdle-ssh-kex-sha2
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: Wed, 10 Feb 2021 07:44:11 -0000

Benjamin Kaduk <kaduk@mit.edu> writes:

> Hi Mark,
> 
> On Tue, Feb 02, 2021 at 03:13:05PM -0800, Mark D. Baushke wrote:
> > Hi all,
> >
...elided...

> There were a few things that I wanted to mention separately, though:

...elided...
> The table in the IANA considerations disagrees about the implementation
> recommendation for gss-group16-sha512-* with the table in Section 3.3.2
> (SHOULD vs MAY) -- your previous messages to the list suggest that MAY
> is intended, and I mostly assume that the SHOULD crept in during the
> rewrite for the -12, when making the non-GSS group16 method 'SHOULD'.

Yes. MAY is what I intended. The SHOULD is probably from doing a quick
replace for diffie-hellman-group16-sha512 which is marked SHOULD. I think
sticking with MAY is okay here, so I will update it in the -14 edition.

> There's also a line in Section 3.2.3 (ecdh-*, ecmqv-sha2, gss-nistp*)
> that says "this set of methods MAY be implemented" when the tables and
> other prose say "SHOULD" about ecdh-sh2-nistp*.  The "MAY" would line up
> with ecmqv-sha2, that otherwise is not mentioned in this section other
> than the table, but ecmqv-sha2 is not really a "set" of methods.
> I'm not sure what the intent was for that text (maybe it's just stale?);
> my current proposal is to just remove it, but that doesn't do anything
> to address the lack of prose about ecmqv-sha2 in this section.  (It might
> also have been referring to the general set other than the specific named
> curves.)

It was indeed stale text and will be removed in -14.

> I also went through the references, with these comments:
> 
> Section 8.1
> 
> RFC 8031 is just about curve25519/curve448 for IKEv2, and I don't see a
> need for them to be normative references for us -- 8731 is (AFAIK) the
> relevant SSH reference.

Agreed. I will move 8031 to informative and 8731 to normative.

> Section 8.2
> 
> We may get some people asking for RFCs 4419, 4432, 4462, 5656, 8731, and
> 8732 to be moved to normative references.  In my opinion it's debatable,
> so I'm happy to leave them as-is for now -- they're all standards track,
> so there would not be a process issue if we had to move them after the
> IETF LC.

I seem to recall getting feedback from someone that they should be
informative.

> I'll include the editorial notes below for visibility and in case they
> help Mark decipher my proposed changes, but I don't expect anything
> noteworthy that's not (also) mentioned above.

Thanks.

> Thanks,
> 
> Ben
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> Section 1.1
> 
> > At present, the attacks against SHA-1 are collision attacks that
> > usually rely on human help rather than a pre-image attack.
> 
> nit: I think a comma before "rather than" would help.

Will be fixed in -14.

> > Transcript Collision attacks are documented in [TRANS-COLL]. This
> > paper shows that the man in the middle does not tamper with the
> > Diffie-Hellman values and does not know the connection keys. However,
> > it manages to tamper with both Ic and Is, [...]
> 
> nit: it looks like RFC 4253 writes these as "I_C" and "I_S" (though
> maybe native subscripts are better yet).

Will be fixed in -14.

> Section 1.2.1
> 
> > For ECC, it is recommended to select one with approximately 128 bits
> > of security strength.
> 
> nit: s/one/a curve/

Will be fixed in -14.

> Section 1.2.2
> 
> > For FFC, a modulus 2048 bits (112 bits of security strength).
> 
> editorial: it's not clear what this not-quite-sentence is trying to say.
> If we wanted parallelism with §1.2.1, it would be "it is recommended to
> use a modulus with 2048 bits (112 bits of security strength)", but since
> after the table we go and list an explicit minimum of 2048-bit MODP
> group14 it's not entirely clear that that's the intent.

The -14 draft will use

            For FFC, it is recommended to use a modulus with 2048 bits
            (112 bits of security strength).
 
> Section 1.2.3
> 
> > The only IFC algorithm for key exchange is the RSA algorithm via
> > [RFC4432].
> 
> nit: s/via/specified in/

Will be fixed in -14.

> Section 3.1
> 
> > diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are
> > currently mandatory to implement (MTI). [...]
> 
> I'd suggest avoiding "currently" (due to the ambiguity of whether it
> applies to the state of affairs before or after the publication of this
> document, when the reader will be reading it after publication) and
> favoring "prior to the changes made by this document, [...] were
> mandatory to implement".

Will be fixed in -14 to use "Prior to the changes made by this document,"
at the start of the paragraph.
 
> > SHA-1 has security concerns provided in [RFC6194].
> 
> nit: s/provided/documented/ or something like that

Will be fixed in -14.

> Section 3.2.1
> 
> > These key exchange methods are described in [RFC8731] and [RFC8732]
> > and is similar to the IKEv2 Key Agreement described in [RFC8031].
> 
> nit: singular/plural mismatch "are described"/"is similar".

Will be fixed in -14.

> Section 3.2.2
> 
> > This Key Exchange Method is described in [RFC8731] and is similar
> > [...]
> 
> nit: since we added gss-curve448-sha512-* to this section we have to go
> to "methods are described" and "are similar" just as in §3.2.1.

Ack.

> > This method MAY be implemented.
> 
> nit: may also need to reword this to just cover curve448-sha512.

Ack.

> Section 3.2.3
> 
> > At present, there are three named curves in this name-space which
> > SHOULD be supported. They appear in [RFC5656] in section 10.1 Required
> > Curves all of the NISTP curves named are mandatory to implement if any
> > of this RFC is implemented.
> 
> nit: "at present" may not age as well as "at the time of this writing".

Will be fixed in -14.

> nit: I think the intent was maybe to format this as """section 10.1
> ("Required Curves").  All of the NISTP curves named therein are
> mandatory to implement if any of that RFC is implemented".

Will be fixed in -14.

> > This set of methods MAY be implemented.
> 
> Is this sentence stale text?  AFAICT it refers to the same
> ecdh-sha2-nistp* that are SHOULD elsewhere in the section.
> But if it referred to ecmqv-sha2 then the "MAY" would make more sense.

The intent was ecmqv-sha2 would be MAY. Also, any OID-based curved MAY
be implemented. This section may need better editing to get the point
across.

> > The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
> > used by ecdh-sha2-* names. The table provides guidance for
> > implementation.
> 
> This would be a good place to put a reference to RFC 8732.

Agreed. Will be fixed in -14.

> Section 3.3.1
> 
> > [RFC8270] mandates implementations avoid any MODP group
> 
> nit: "mandates that"

Will be fixed in -14.

> Section 3.3.2
> 
> > diffie-hellman-group14-sha256 method MUST be implemented.
> 
> nit: "The".

Will be fixed in -14.

> Section 3.4
> 
> > Uses an RSA 2048-bit modulus with a SHA2-256 hash.
> 
> nit: "It uses"

Will be fixed in -14.

> Section 6
> 
> > It is desirable to deprecate or remove key exchange method name that
> > are considered weak. A key exchange method may be weak because too few
> > bits are used, or the hashing algorithm is considered too weak.
> 
> nit: this is not an exhaustive list, so we could tweak the wording.
> 

Good point. I guess your suggestion of ", or for other reasons" like

        It is desirable to deprecate or remove key exchange method name
        that are considered weak. A key exchange method may be weak
        because too few bits are used, or the hashing algorithm is
        considered too weak, or for other reasons.

at the end of the paragraph is one way to address this.

Other suggestions from the list greatfully considered.

	Be safe, stay healthy,
	-- Mark