Re: [Curdle] RSA key transport for SSH (RFC 4432) and forward secrecy

Benjamin Kaduk <kaduk@mit.edu> Thu, 11 February 2021 19:21 UTC

Return-Path: <kaduk@mit.edu>
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 6BE683A1884 for <curdle@ietfa.amsl.com>; Thu, 11 Feb 2021 11:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PcNHw52H_ASp for <curdle@ietfa.amsl.com>; Thu, 11 Feb 2021 11:21:53 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AACB13A1883 for <curdle@ietf.org>; Thu, 11 Feb 2021 11:21:53 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11BJLdAN031402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Feb 2021 14:21:44 -0500
Date: Thu, 11 Feb 2021 11:21:39 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Mark D. Baushke" <mdb@juniper.net>
Cc: Simon Tatham <anakin@pobox.com>, Ron Frederick <ronf@timeheart.net>, Alexandre Becoulet <alexandre.becoulet@free.fr>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "curdle@ietf.org" <curdle@ietf.org>
Message-ID: <20210211192139.GA21@kduck.mit.edu>
References: <20210211042551.GV21@kduck.mit.edu> <1613018828089.63687@cs.auckland.ac.nz> <94759.1613022658@svl-bsdx-06.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <94759.1613022658@svl-bsdx-06.juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/-JePRJ4I-AR-Q8w0LMhELLoqq18>
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 19:21:55 -0000

Hi Mark,

On Wed, Feb 10, 2021 at 09:50:58PM -0800, Mark D. Baushke wrote:
> [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).

That perhaps came across stronger than I had hoped for -- AFAIK the RFC
does what it says to do and says what it does; it's just that what it does
may no longer reflect what the IETF currently considers to be best
practices, and I'm pondering how we might go about recording that in some
official-ish way.

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

To clarify: my intent and expectation was that we consider this question
separately from the advancement of draft-ietf-curdle-ssh-kex-sha2.  We may
want to think on this question for a while, and that draft is otherwise in
good shape and shouldn't be further held up.

>     Ben desires data and it is my suggestion that the supporters for the
>     implementations that provide for rsa2048-sha256 may information on
>     this topic.

Indeed, and thanks for all the responses received so far.

-Ben