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

"Mark D. Baushke" <mdb@juniper.net> Thu, 25 February 2021 02:12 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 2959D3A0C7A; Wed, 24 Feb 2021 18:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level:
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mNmeygkk; dkim=pass (1024-bit key) header.d=juniper.net header.b=CrgaXIod
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 CwtEULRgUFi3; Wed, 24 Feb 2021 18:12:38 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 2E6373A0C74; Wed, 24 Feb 2021 18:12:38 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11P29BfI029557; Wed, 24 Feb 2021 18:12:32 -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-id : date : message-id; s=PPS1017; bh=uneOkWlQxzGBTrepHg1HVaiINbKThciLNU0s8bLT5wo=; b=mNmeygkkn2aF0SxMbfcPKHKEnTx33Rbsh2i03MkqR8cM0nI8gPXyEz3pduLDbHblLEcQ xFJrEvTB5T46E3Upf6WbmwnCavLIysrfU0LeWdOy+AjQlCJksxCNp0AsG59B5LtMMTuS 2vef4NUqOb6xshFFDOMwVDSIM/PP8UtJlLUYbhhIA7OiBuQNMGgtXkmPLFBc8A9jzZkj IZjE/0letXR82Y73RFCFpxL+PE2r73YXirygmuP8oJzW9n2EHP/6voWVr5P5En2XNZj0 4eCvn0RNN+S8VBKMMwXPwBi8nf6XcM7d/R5WWAFAXL6iClNB4QfBZbFsIUGFm8zSc48g pg==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0a-00273201.pphosted.com with ESMTP id 36u2auskjx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Feb 2021 18:12:31 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i566qfXjxo638OFFgZZZBAEcC4ED6VS8JbQ//vsXwHN2cl9yMtDh8N8LP6Zjv8sm/nfUVca5QpvD3TG0xs0XA5XdaTIlpN7VUab3wCGlmR3o0Ef4htDns/NhT3P54svpf0RT2f4dCEuyPS2Mf0CIEgHYCLTIN+WfSCuyhPq+buk8FXpKI3w5/iqbeF8PRJ7ffDlr4T8qwf15lQ1G+eW16WuVMiWeEJ+UGqP3OoL+e76tq3bVVsYXNUQNO8fRlS7cXDNs7QSzGTIJGboPJJ3tm/3fIv42TmdrrkLBftOTnFrOQdW5smBidAMT1dzz9cC/v7SqDYEJIFTvj3M1GZetVw==
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=uneOkWlQxzGBTrepHg1HVaiINbKThciLNU0s8bLT5wo=; b=bWNsIBceVWi3WfrN4OPnMzNTmfHft7V9bzq3N2PzYstnooU1LNJYAYPudoaNExdOBu0Q406N4jq+R/QdotynmtDByiKTop+UzSGrJ3QQalMiNuxmDkWqLvALa00Qhuu4gpRvHzeiMsCZdmJK8R67PMHxo14Wx5Mcwe6+kKTyuUayUVOuo7lvcHZ0bN/xRgF1VdzHGk6YvkKEvlkRGOkF/3II72aAOPxyTq6CaTQnj+mUb+RjqWSoCPQPF6weHncP/LUq6q84z1woKElMZ+PWhnJ+kYEVzORGiRyHJojK82VLiBdsr8itGuhefQJzbqO67fsn6AtmzzL3dDWmEEDh1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.13) smtp.rcpttodomain=ietf.org 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=uneOkWlQxzGBTrepHg1HVaiINbKThciLNU0s8bLT5wo=; b=CrgaXIod/ihbvcfaOnGBEvlsXfAsg38QmLbV2ll4RjVqKH1uk+pAN6Wr8nS7KHHeFzX/jquHnka/jWeNDNyLVvILIzJsbSTwrWYVUX1leEuZynh/iHcRJrteORgXaxqUrAmsmIJorKTPLJyrJ25Pf90d8wvo9ydg7ti3FbB81fM=
Received: from MW4PR04CA0106.namprd04.prod.outlook.com (2603:10b6:303:83::21) by SN6PR05MB4526.namprd05.prod.outlook.com (2603:10b6:805:36::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.11; Thu, 25 Feb 2021 02:12:29 +0000
Received: from MW2NAM12FT006.eop-nam12.prod.protection.outlook.com (2603:10b6:303:83:cafe::69) by MW4PR04CA0106.outlook.office365.com (2603:10b6:303:83::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 02:12:29 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.13) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by MW2NAM12FT006.mail.protection.outlook.com (10.13.180.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3890.8 via Frontend Transport; Thu, 25 Feb 2021 02:12:29 +0000
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Feb 2021 18:12:29 -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; Wed, 24 Feb 2021 18:12:28 -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; Wed, 24 Feb 2021 18:12:28 -0800
Received: from svl-bsdx-06.juniper.net (svl-bsdx-06.juniper.net [10.160.3.21]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 11P2CRoE024890; Wed, 24 Feb 2021 18:12:27 -0800 (envelope-from mdb@juniper.net)
To: Rene Struik <rstruik.ext@gmail.com>
CC: <last-call@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, <curdle@ietf.org>, <daniel.migaultf@ericsson.com>, <curdle-chairs@ietf.org>, <draft-ietf-curdle-ssh-kex-sha2@ietf.org>
In-Reply-To: <ef2702b2-deec-9d7f-2641-0d2b79e819c4@gmail.com>
References: <161297636786.23628.11474505782744804904@ietfa.amsl.com> <ef2702b2-deec-9d7f-2641-0d2b79e819c4@gmail.com>
Comments: In-reply-to: Rene Struik <rstruik.ext@gmail.com> message dated "Wed, 24 Feb 2021 17:46:29 -0500."
From: "Mark D. Baushke" <mdb@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27418.1614219147.1@svl-bsdx-06.juniper.net>
Date: Wed, 24 Feb 2021 18:12:27 -0800
Message-ID: <27419.1614219147@svl-bsdx-06.juniper.net>
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: 3ff0388b-93f8-4451-07c5-08d8d932cdac
X-MS-TrafficTypeDiagnostic: SN6PR05MB4526:
X-Microsoft-Antispam-PRVS: <SN6PR05MB45262D2D5D67914E21F4178ABF9E9@SN6PR05MB4526.namprd05.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: zhtsCnhvpOS9mXqc27YoO9FuOONU+9PsCO64OEE1AtZgwfh9ZzP/MFkCYNzF2rO8Zw86Cpoxvzwos/CXGqbRHqV2K3vdxMIkYtlHZxVR7r8XIShbmRF9Dg6CcYWz7l2rp0UGYgW5jeMY6o6mLsgwCjcsjnquaCgV8qeGUfC0INoN9/s5d6CEflWgOp74a6L1NwkaB3QJRLt+Dt3Y97AJgDUYHjNLMkE+KNs7aYnYZYPTLjh4Ua06JXEF4ZWVlPCVjVdSXjKO76OFv0xKe4pnI9/yVDHzew4r9qzFcmDF1J0WDMn0B7Dx/eazLakamuV9/vcAXuMY3RxmD1EJpAfKVPDSscPQdT1qY9Bq/j/sIYurf9ZIQB8xnQyihrY4srh2QpEPlSCFeyKZeiBCZQ6XofUzobBGsxL++iXYap2jrdAfrJ5OJKB4vqxX1h5JVwiS7l/+M0Y6kyyhHxx5rW+98AItZCNLJ+Ja/ZVzztiaVrUmnhZHdqeQK0qQCMmXWRJtYucpoYryPLu52BIu6WfS6zolqvDrJsql3Ox841sjOsMm1N+SZwmr5/UyJv7OXPCNl76kVcEMc5XeN154OEVoqOGj7iB9a/92b75746ROB+fLPF4ayb+FgqtSA0Vvc+xGUoclpAL7f2fa1h0tnQgKUF2kf0kcmipGNEQH/C/l6rqlK0RkRh/ql3IXnaP8fAR9
X-Forefront-Antispam-Report: CIP:66.129.239.13; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:P-EXFEND-EQX-02.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(136003)(346002)(39860400002)(396003)(376002)(36840700001)(46966006)(5660300002)(478600001)(316002)(70206006)(82740400003)(47076005)(2906002)(83380400001)(82310400003)(54906003)(26005)(186003)(336012)(7696005)(81166007)(4326008)(36860700001)(70586007)(426003)(6916009)(8936002)(8676002)(356005)(86362001)(15650500001)(36900700001); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 02:12:29.4131 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ff0388b-93f8-4451-07c5-08d8d932cdac
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.13]; Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT006.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4526
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-24_13:2021-02-24, 2021-02-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 malwarescore=0 mlxlogscore=976 phishscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 spamscore=0 adultscore=0 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102250015
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/zxRYMDtGbcGhz2bOEe3wPuW6nbw>
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-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, 25 Feb 2021 02:12:40 -0000

Hi Rene,

I have tried to address all of your comments below.

Rene Struik <rstruik.ext@gmail.com> writes:

> Dear colleagues:
> 
> I did have a brief look at this draft and have the following (small)
> comments:
> 
> Draft: draft-ietf-curdle-ssh-kex-sha2-14
> 
> Comments:
> - 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?

MDB:

As the draft author, my original intention was to move all of the *-sha1
key exchanges to either deprecated or disallowed. In RFC keyword terms,
this is SHOULD NOT or MUST NOT. If you look at Table 6, the only one
that was missed was the former "MUST" algorithm
"diffie-hellman-group14-sha1" which has been moved from "MUST" by
RFC4253 to "MAY by this draft.

The WG consensus was that this "MAY" allows for a transition period to
the new "MUST", "SHOULD", and "MAY" guidelines for key exchange methods.

> - 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?

MDB:

I can add it if it is desired by the community. Or, I could remove any
mention of SHA-224 if that would make the community happier.

I will note that RFC5656 section 6.3 mandates that ecdh-sha2-nistp384
use SHA-384 which is why there is no similar language for that hashing
algorithm.

> - 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}.

MDB:

I do say 'approximately 128 bits' in the text. I could add the word
'approximately' to the table if that is needed for consistency.

Do you have an informative reference for Curve448 being at 223 bits of
security rather than 224 bits? If so, I could add it to the
informational references and update the table.

> - 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?

MDB:

I thought the section 3.2.2 text was clear that the key exchange method
names were those found in RFC8731.

Section 3.2.2 specifies curve25519-sha256 for two reasons:

  a) it is a direct documentation of curve25519-sha256@libssh.org which
     is deployed in many SSH implementations and is documented in
     RFC8731.

  b) SHA-3 implementation were not as widely deployed as SHA-2 when the
     curve25519-sha256@libssh.org implementation was created.

If you have any suggestions for how to make section 3.2.2 clearer, I
have no pblems with updating the section with such a consideration to
help readers of the RFC.

> - 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). 

MDB:

Yes, and it is only FFC group14 which already in fielded implementations
due to RFC4253 mandating it (for use with SHA-1). The only change was to
move from SHA-1 to SHA256. This was considered to be a simple code
change as compared to trying to add EC to implementations that do not
have it and are not interested in implementing it.

> 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)?

MDB:

The nudge I used was marking them as "SHOULD" ... I was unable to get
consensus on MUST for any of the EC key exchange methods.

That said, there are again two plausible reasons for this:

 a) In a Post Quantum Cryptography (PQC) world (which I do not expect to
    happen in my lifetime), it is easier to break EC than FFC because EC
    uses fewer bits.

 b) If you look at the archives, you will find a number of implementors
    refuse to consider a move to EC key exchanges at all.

So, one reason is technical and one reason is mistrust of EC... or maybe
they are both anxious about PQC.

I feel happy I was able to make rsa1024-sha1 a MUST NOT as there are
still a lot of folks that enjoy using RSA. and I would have no problems
if rsa2048-sha256 were removed due to a lack of perfect forward
security.

> - (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?

MDB:

Given the key exchange method names are sent in the clear of the fixed
sized prime fields for FFC and curves for EC and key size for RSA, I am
unclear on your point. There is not really anything secret about the
sizes of these crypto variables.

If you are talking about mpint for other parts of the SSH protocol, then
that may be worth a larger discussion.

> 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.])

MDB:

At this time, the CURves, Deprecating and a Little more Encryption
(curdle) working group is winding down. I believe that the this draft is
the second to the last one for the WG. (The only one still waiting is
draft-kampanakis-curdle-pq-ssh-00)

I would suggest that the ietf SSH working group would need to be
restarted if there was going to be a design update to move from SSHv2 to
SSHv3. However, that is just my opinion.

> Best regards, Rene
> 

I hope that my answers have addressed your questions and concerns and
look forward to any suggested textual changes to make the document
better.

...elided the rest of the message...

	Be safe, stay healthy,
	-- Mark