Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy
"Mark D. Baushke" <mdb@juniper.net> Thu, 11 February 2021 05:51 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 A20373A1267 for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 21:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 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, 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=qFtGPqdZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=kY4/duuH
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 Y5VqPEz800YZ for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 21:51:11 -0800 (PST)
Received: from mx0b-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 C408E3A1266 for <curdle@ietf.org>; Wed, 10 Feb 2021 21:51:11 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11B5nMHs017054; Wed, 10 Feb 2021 21:51:04 -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 : content-transfer-encoding : date : message-id; s=PPS1017; bh=txEq0DeuempwnY1uPUvfZZ1DQEucRPcSIwmewFoPOGc=; b=qFtGPqdZu7mwM5AThj19/E21+KHmgjzREYd2jAaceCN+MmFg8iSm66Y9H09vFWci45eI PPWgnbBjHM8H0/oGBbZIRkmOOOpf+Bq0mq6EVKmW4bWGbw1XsAme2K6sSgBLn9bhlyPm a3TDCkjUEGt1fj6+XuZoWVaZJ8MM2kXoAQ/4ck14ow7S0GgFmOjy5Hhm6D7E9qTuh/4Q 5+kZ8CgKS6uFTAMlZRtywOuq5q2t4SIBZVvfWKc1+9MrKZGTBeGPPu3dzW016YLUhW1p fhlg4+uZsBKD3wqrf1drzLPglDNcOc1oJhlt5fNVrl8VdKy97yyclxa28mkaCDMQuTN0 DQ==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by mx0a-00273201.pphosted.com with ESMTP id 36jqcp7b6x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Feb 2021 21:51:04 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ov+f9dfJlvehIPvByCF+DffwCaSKDSd2tt5SDvuozLRsNNK6TmS1OEGG7KWkT+rhQtFkeHBT0L58FD9gcayXxKBTf4iAVdqHAoW8SLJ//Mi00AT4eeL5Bx2hmYstlhve1YyUXlAXI+PLNgGL1JT4m9Wgo53gxBTMZXSuc+5FlKQyPKsUbKE9qyQwjGlI6Nc1L0vCFtzSciS1D1hvH7Y0NNB5XmwAKtJQ9D09yGG6Gn3Dl+P+Ip1mMGTBG6KIxBBCm06f+HOuQAeGxUYn2dYBpdrhXIFW07N9zgi7lJ6WSIn/RZ7rBPXwsB7idrcEdPmTlU2XK2LYoj/Lug4JWsyCtg==
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=txEq0DeuempwnY1uPUvfZZ1DQEucRPcSIwmewFoPOGc=; b=G6Z1vJGHLr3/D+Q0aJHRcH1ho7sLyPtdX0C8DfxjVURRR5Y2jP4E/vQtQs0K4nkgsDNEw5wJYKKMfaV4GOeEqdWF2AMzS5Od84ozemE42rFrjA68BrOFodeRxR2dmprj/GVZJLsn7cDcqwixlk+hv0Y7PinOKAbwnIBk8dHh11HC+ydiMcbNkZP+VrDS88Br8KcgodPyg6CA5Xgp+2kHI8UFlVyGm0J31hR4CLRLDTTEOpsi1Xe4s+kb6ZxFXTSZO9MjOO6APl6AmjoR+lkXPdINauRvlffhNY2awAleDbolQ1r54wSYOZQTjAh0hCUYbNHhFDHZBRHa+TvmV7HxMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.12) smtp.rcpttodomain=free.fr 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=txEq0DeuempwnY1uPUvfZZ1DQEucRPcSIwmewFoPOGc=; b=kY4/duuHG/19pg8QoEyX41tu50XNiggXon5CdG+rDRWqXrHd2Oi2nM11//WIjEZ2ZJcDMslcy0taHTFUeyZhu4LgeXoUGniv752EKJJ9xA2+6b57v/U93itrmTnGPX//iL3W1QUsrRyzsWqPAJLiUN9a/I/oXBVN9z1K/gOPfvQ=
Received: from MW2PR16CA0059.namprd16.prod.outlook.com (2603:10b6:907:1::36) by MWHPR05MB3072.namprd05.prod.outlook.com (2603:10b6:300:b3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.11; Thu, 11 Feb 2021 05:51:01 +0000
Received: from MW2NAM12FT032.eop-nam12.prod.protection.outlook.com (2603:10b6:907:1:cafe::f0) by MW2PR16CA0059.outlook.office365.com (2603:10b6:907:1::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Thu, 11 Feb 2021 05:51:01 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; free.fr; dkim=none (message not signed) header.d=none;free.fr; 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 MW2NAM12FT032.mail.protection.outlook.com (10.13.180.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3846.25 via Frontend Transport; Thu, 11 Feb 2021 05:51:01 +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; Wed, 10 Feb 2021 21:51:00 -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, 10 Feb 2021 21:51:00 -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 11B5owMO007452; Wed, 10 Feb 2021 21:50:59 -0800 (envelope-from mdb@juniper.net)
To: Simon Tatham <anakin@pobox.com>, Ron Frederick <ronf@timeheart.net>, Alexandre Becoulet <alexandre.becoulet@free.fr>, Keith Winstein <keithw@mit.edu>, Hari Balakrishnan <hari@mit.edu>, mosh-devel@mit.edu
CC: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Benjamin Kaduk <kaduk@mit.edu>, "curdle@ietf.org" <curdle@ietf.org>
In-Reply-To: <1613018828089.63687@cs.auckland.ac.nz>
References: <20210211042551.GV21@kduck.mit.edu> <1613018828089.63687@cs.auckland.ac.nz>
Comments: In-reply-to: Peter Gutmann <pgut001@cs.auckland.ac.nz> message dated "Thu, 11 Feb 2021 04:47:07 +0000."
From: "Mark D. Baushke" <mdb@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <94756.1613022658.1@svl-bsdx-06.juniper.net>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Feb 2021 21:50:58 -0800
Message-ID: <94759.1613022658@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: 3c9ed355-f98a-4002-9d0e-08d8ce510366
X-MS-TrafficTypeDiagnostic: MWHPR05MB3072:
X-Microsoft-Antispam-PRVS: <MWHPR05MB3072678354B0DBE843864662BF8C9@MWHPR05MB3072.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: Sqw9yKzOM1LyYEFHfmQLaM5pGyIKYbbc/6XKoKm1OfpP3ZlLqTD8SguU8JCG/IlfaUnHSz64RfVA86d7bP09peJNbEwz+vwY6zLvuqilCML3d9K08QNZcpgKTPLDh+Q/uQwASMCShJOAgxoZUX3a2NQZvjThEcwCgwpaW8CC6OUNLiBks68BASNeX4IyuMOhO3SQ8BY85AiKcmGk3Tz0FgORGiM6e+ugJjOjZyJZ6kLdo4nzlZ2xQiyg67J4cKgpGUwl0X8k95YXyy+bFT8hAZ7w1LKJojNegSQeiyyD8yl52narThrm1g7+GOhZoHkWTDD51kUgWbItaeUKHl7aIm3OhjYRKEXQ/iLbw2BGcNP2cxhpIavxd6f2p+D2HijZlzTudXqDhMvNe9+mpkfGYtdUZde2jlptcF251wLpTvijb9vMaDvENRWiyQDNo+qSDqqT5U8QkTp/1iXRPBSC9U06pcr7+wNjx5L2Ln6QzeNnzV/Zw5Zl+rLib9S0yYws6PQHMStSvg2Bva4P/yIxK1kufJbpxf6/r97so74qV95bvn+9FAQ2dIkUzmhzkRuEYR51Kacd+ZQUi8cYVECoM816RfDHGzFvG2LPotLSHho31tTBkprzNf9wd4xZ4ionubrTPVklF+27d0oYgT9AHOC1FcVrWRDpDEFd+ISTSx4oqi/VYPjDY9ykH8Vj8CfzqJN7sVylTenbgp6PMSY7/WP2ge+Zcl5bwbjwihOgzTI5kzuOkktOcOYQ5itK0joXovqkTOZbVchC+IvfT22Pr41Z9gPFYxVxJbXQigAi/ws=
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)(346002)(136003)(376002)(396003)(39860400002)(46966006)(36840700001)(83380400001)(86362001)(82740400003)(70586007)(83080400002)(8676002)(82310400003)(70206006)(5660300002)(478600001)(81166007)(966005)(4326008)(356005)(54906003)(186003)(26005)(8936002)(7696005)(426003)(336012)(47076005)(110136005)(2906002)(316002)(36860700001)(36900700001); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2021 05:51:01.6595 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c9ed355-f98a-4002-9d0e-08d8ce510366
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: MW2NAM12FT032.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3072
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-11_05:2021-02-10, 2021-02-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 bulkscore=0 mlxscore=0 phishscore=0 adultscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102110050
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/iXaBRipsfY6mMoqPCyLRnZHFQ2s>
Subject: Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy
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, 11 Feb 2021 05:51:14 -0000
[To+ Ron, Alexandre, mosh-devel, Simon] question on rsa2048-sha256 KeX for SSH Summary: Is anyone actively using rsa2048-sha256 for a Ssecure Shell Key exchange per RFC 4432. The Security Area Director Benjamin Kaduk has concerns regarding this Key Exchange Algorithm (see messagess below). The IETF Draft https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ is presently in Last Call. This draft is in the process of suggesting "MUST NOT" for rsa1024-sha1. The question on the table is if the same rating should be appled to rsa2048-sha256 or if RFC 4432 should itself be moved to historical, or if this is still a useful key exchange being actively used. Ben desires data and it is my suggestion that the supporters for the implementations that provide for rsa2048-sha256 may information on this topic. Comments welcome. Hi Ben & Peter, To Peter's question, my straw poll was explicitly about the *-sha1 Key Exchanges which did not include the rsa2048-sha256 kex. If I go to https://ssh-comparison.quendi.de/comparison/kex.html I see that rsa2048-sha256 is supported by the following implementations: AsyncSSH (maintained by Ron Frederick) libassh (maintained by Alexandre Becoulet) Mobile SSH (aka Mosh via mosh.org and <mosh-devel@mit.edu>) (original paper authors Keith Winstein <keithw@mit.edu>, Hari Balakrishnan <hari@mit.edu>) PuTTY (maintained by Simon Tatham) There may be other implementations that are not in the comparison chart, but I think this may be a good start. I have added both Ron, Alexandre, mosh-devel@mit.edu, and Simon to the TO line for this message. Thank you for your participation in this thread. Be safe, stay healthy, -- Mark ------- original messages ------- Date: Wed, 10 Feb 2021 20:25:51 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: curdle@ietf.org Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/uo-OEckOhU8CKCzwwws6kKNsM2s> Subject: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy While reviewing draft-ietf-curdle-ssh-kex-sha2, I followed many of the references, which included RFC 4432, which defines the "rsa1024-sha1" (getting deprecated for SHA-1 usage) and "rsa2048-sha256" (which is not) key exchange methods. While the specific construction is claimed to still produce contributory behavior in practice (due to the client-contributed key only ever being used in combination with the hash of server-provided data), it seems to still be the case that if the RSA private key is revealed, the session key is revealed, which is mostly the standard non-forward-secret behavior. Things are perhaps better if you buy into the theory that "it may be a transient key generated solely for this SSH connection, or it may be re-used for several connections" is supposed to prevent indefinite reuse of the RSA keypair, which seems ... not very reassuring. While it's not clear to me that there's specific reason to (say) move the whole RFC to Historic status or claim that it is obsoleted by some more-modern key-exchange method, it does seem likely to me that we could get IETF consensus that actually using rsa2048-sha256 is generally a bad idea. (Or maybe we could get consensus to move it to Historic.) Perhaps an RFC 2026 Applicability Statement would be an appropriate tool for this case? But most likely the best place to start would be to ask how widely it's implemented and if it's known to be in use anywhere...does anyone have data? Thanks, Ben _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------- message 2 ------- From: Peter Gutmann <pgut001@cs.auckland.ac.nz> To: Benjamin Kaduk <kaduk@mit.edu>, "curdle@ietf.org" <curdle@ietf.org> Date: Thu, 11 Feb 2021 04:47:07 +0000 Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/vwS-A4E04Mg1A8avNfWqaXtZli0> Subject: Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy Benjamin Kaduk <kaduk@mit.edu> writes: >But most likely the best place to start would be to ask how widely it's >implemented and if it's known to be in use anywhere...does anyone have data? We could start with Mark Baushke's KEX straw poll from a month ago, I think pretty much everyone voted RSA a MUST NOT which would indicate that no-one's going to miss it. Peter. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------- end of original messages -------
- [Curdle] RSA key transport for SSH (RFC 4432) and… Benjamin Kaduk
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Peter Gutmann
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Mark D. Baushke
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Peter Gutmann
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Keith Winstein
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Mark D. Baushke
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Ron Frederick
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Benjamin Kaduk
- Re: [Curdle] RSA key transport for SSH (RFC 4432)… Simon Tatham