Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard

Rene Struik <> Wed, 24 February 2021 22:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33EB73A1CB7; Wed, 24 Feb 2021 14:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KL1QO7dkMlJi; Wed, 24 Feb 2021 14:46:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 380CE3A1CB6; Wed, 24 Feb 2021 14:46:33 -0800 (PST)
Received: by with SMTP id b3so2759276qtj.10; Wed, 24 Feb 2021 14:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=j22BMuJgF0e3yLBd59ST/SDJwI2z0xoUMSdXy77fbbM=; b=sciHD6QlppjhwymE081iovfGW/9VgGbr8pj89LKgU3IayXhcLj4OX8eanvWO/F147J 6iDemlzvMaKSmVLxQKvkLh4lEp4vDXL574x9H2RsQry+4daRUHFLu1qRrYi+XK8hqP/B Tf1If1twune3wzFtY2YVB3hetE8/lMdCPSRuq1uFQNOzkHRpDGEfcP6ci+sJMA3Xr+TN cWOfAQS5cUGBSuwtXrdcZVe5gYaLKNRhEq5KoHn3l+f7XPKwuH49BwnPASSOVIFcKZDZ dudiuHpYVvDYIwZdGaPf5GzKkN0F3LDw1sK2f9JT0LrtRbOEUqQaN0XFbovXzG+iOml5 MHUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=j22BMuJgF0e3yLBd59ST/SDJwI2z0xoUMSdXy77fbbM=; b=T5st99fb98vEJ4QSE4FSsNzM81e/qBwv/dIWKOQ2838Ic3tgqtW6ZpC9CyJXS2n0m6 PvbnXHrUBH0MfrDobqchVudC4N8uBZZGDTRoGT+6mKff/lsdKJB4wqxDywcmF4XKW+/M J4kyDhiLRKWYTXO/BKJQa0aO7gA6jv3/Z9Ox6LnpLzrjOPKnZ4Xis3PzFtm7SEHJVAa+ FyUEbrv+r6zAPX+Z8a9ICCgFH4N1cMxC9XSLEXfAOvGqPuMCjbtwUUad/g1dlG64NcR2 tlWt1KdySkNqJLcy05u2PtwtJHThGgUPUlFNBtZ4YT9Au0AjwH/wIIiXm21oNBkzsA8i 55Nw==
X-Gm-Message-State: AOAM5336mqI2xwg3SDUeX/Ddgwvk8ftHqPZXHkPn9AZX40e2u4L4//Po W2bm0dYfcD/m2uuNIn2NCmgMFXlihw4=
X-Google-Smtp-Source: ABdhPJxIud4CqPdqd+2NVWAsx8OXLnKebTMRZ+FXjp1H776xqgCoZf7spdhcfHdyhNT35ZRqnel1Pg==
X-Received: by 2002:ac8:4418:: with SMTP id j24mr55465qtn.250.1614206791906; Wed, 24 Feb 2021 14:46:31 -0800 (PST)
Received: from ?IPv6:2607:fea8:8a0:1397:b015:b65a:26d0:15a2? ([2607:fea8:8a0:1397:b015:b65a:26d0:15a2]) by with ESMTPSA id u1sm898547qkd.13.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 14:46:31 -0800 (PST)
To:, IETF-Announce <>
References: <>
From: Rene Struik <>
Message-ID: <>
Date: Wed, 24 Feb 2021 17:46:29 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2021 22:46:35 -0000

Dear colleagues:

I did have a brief look at this draft and have the following (small) 

Draft: draft-ietf-curdle-ssh-kex-sha2-14

- the document seems to take a half-hearted stance on deprecating the 
use of SHA1. Why not simply strike all key exchange methods that use it 
off Table 6 altogether?
- in Section 1.1 (p. 3, forelast para), it is suggested to not use 
SHA-224 since it has the same compression function as SHA-256 (and only 
differs from it by the initialization vector and truncation in the end). 
Shouldn't one add similar language for SHA-384 vs. SHA-512?
- in Section 1.2.1, the bit security of Curve25519 and Curve448 is 
somewhat smaller than stated (126-bit and 223-bit) {although perhaps not 
that important a change}.
- in Section 3.2.2, I am somewhat puzzled by the suggested use of 
Curve448 with SHA512, since RFC8709 introduces Ed448 (which uses a 
4-isogenous curve Edwards448 to Curve448, but which uses SHAKE256/d=914 
internally). Why not align the underlying hash functions, so that 
implementations with this curve would be able to use a single hash 
function implementation?
- in Section 3.3, I am wondering about the underlying philosophy of 
still aiming for implementation of ordinary discrete log groups (Note: 
it is the only method with a MUST). Shouldn't one give a nudge towards 
implementing elliptic curve-based methods (which all have a MAY or 
SHOULD only). It seems more appropriate to switch this order and label 
DLP groups as MAY at most (if sufficiently large)?
- (not really in this document, but I thought to ask nevertheless) some 
representations, such as "mpint", do not seem to be such a smart choice 
any more, since variable-size encodings may leak info on secret 
parameters in crypto processing. Is there any reason this still, in 
2021, should be kept as is?

I do realize that not all these comments are directly fixable with this 
draft (e.g., the last one). However, it makes me wonder whether it may 
be time for a more general design update of ssh-related protocols? (in 
my mind, crypto agility should have a complement in general design 
agility... [even if one would just only get rid of mpint etc.])

Best regards, Rene

On 2021-02-10 11:59 a.m., The IESG wrote:
> The IESG has received a request from the CURves, Deprecating and a Little
> more Encryption WG (curdle) to consider the following document: - 'Key
> Exchange (KEX) Method Updates and Recommendations for Secure Shell
>     (SSH)'
>    <draft-ietf-curdle-ssh-kex-sha2-14.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2021-02-24. Exceptionally, comments may
> be sent to instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> Abstract
>     This document is intended to update the recommended set of key
>     exchange methods for use in the Secure Shell (SSH) protocol to meet
>     evolving needs for stronger security.  This document updates RFC
>     4250, RFC 4253, RFC 4432, and RFC 4462.
> The file can be obtained via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list

email: | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867