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

Ron Frederick <ronf@timeheart.net> Thu, 11 February 2021 06:28 UTC

Return-Path: <ronf@timeheart.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 3D3613A12D0 for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 22:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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, 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 (1024-bit key) header.d=timeheart.net
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 ZBUZ1QXDcUDx for <curdle@ietfa.amsl.com>; Wed, 10 Feb 2021 22:28:00 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1183A12CC for <curdle@ietf.org>; Wed, 10 Feb 2021 22:28:00 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id e9so2858646pjj.0 for <curdle@ietf.org>; Wed, 10 Feb 2021 22:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K/lhhA5mtDuQJ/mRzqwAnpTYZr0Pre7vXW6ve5uoBvw=; b=bzPVydgHLPCmh2DQTj37qq94btCnjfG3OGWfm0gdbSR9eWqumtmgYlMJ6y/dYUPYJ3 JNGnQLQEFAQuT8ImMURt7K6VLy5K5k1JKH1pP3Zg9wVSMblan6S/qJjG/8oBDZOcjZAz gfAC0uAA7t5RV92e0Senqz+dp77vptDFSo/nE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K/lhhA5mtDuQJ/mRzqwAnpTYZr0Pre7vXW6ve5uoBvw=; b=p3V+KeRnr3HvNBi6rpW60JX3AApWxPxwfvZnc3bBR05mww8yYgwgJWk4xQ1GY2dvR1 n+/jl6P5sqaf9uTnXX8qjJNsDA0bNALknehzhlT68etpURtlRGJUqYnxULTtx28xV/I4 Ru9fkNjoC62inEXBZI6Bdnj2rxW2WsI0bQMRc9dN7JMKlzwBKkq4NYjQKfzVEtDZ9Ncu JvK8af5c8dQ2XsrhG8mYeVMOc71F0p6FGf98W/StuQ3mMeQBwRSGk08XX1pHVouPv7Kz c4akqzgD6hhq++VTiCU7Qzpxt6Rb3za5lTR+9msLNmj4owjgz+a1I3Js+ASUq1xBYECm ie5A==
X-Gm-Message-State: AOAM532n0QMSUS7KgW0PgZHDBTT9bUsXEYNN3kFRIJfYr91uD1Y+kfjj nQSO5DCZ61kg8XsNL5I8Dvan4w==
X-Google-Smtp-Source: ABdhPJyR7GcuHGmn9koUM9bLf1Ev2/bn+G7Z+75veyZqCV5NcSAslWdEPmO6yrcejXEkGPkEmMM46Q==
X-Received: by 2002:a17:902:b206:b029:dc:1f41:962d with SMTP id t6-20020a170902b206b02900dc1f41962dmr6606356plr.28.1613024878292; Wed, 10 Feb 2021 22:27:58 -0800 (PST)
Received: from quad.timeheart.net ([74.93.13.193]) by smtp.gmail.com with ESMTPSA id v26sm4005747pff.195.2021.02.10.22.27.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2021 22:27:57 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Ron Frederick <ronf@timeheart.net>
In-Reply-To: <94759.1613022658@svl-bsdx-06.juniper.net>
Date: Wed, 10 Feb 2021 22:27:55 -0800
Cc: Simon Tatham <anakin@pobox.com>, Alexandre Becoulet <alexandre.becoulet@free.fr>, Keith Winstein <keithw@mit.edu>, Hari Balakrishnan <hari@mit.edu>, mosh-devel@mit.edu, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Benjamin Kaduk <kaduk@mit.edu>, "curdle@ietf.org" <curdle@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FFDF858-E6A9-4605-BC91-AEB3C6E7AB98@timeheart.net>
References: <20210211042551.GV21@kduck.mit.edu> <1613018828089.63687@cs.auckland.ac.nz> <94759.1613022658@svl-bsdx-06.juniper.net>
To: "Mark D. Baushke" <mdb@juniper.net>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/e08AAlxAYs5xR_0bub0kq6fb-6Y>
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 06:28:02 -0000

On Feb 10, 2021, at 9:50 PM, Mark D. Baushke <mdb@juniper.net> wrote:
> 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.

I added rsa1024-sha1 and rsa2048-sha256 to AsyncSSH back in 2018 to improve compatibility after noticing that there were other implementations out there. Since then, based on discussions on this mailing list, I disabled rsa1024-sha1 by default, but still allow it to be used if explicitly enabled. At this point, rsa2048-sha256 remains enabled in AsyncSSH, but it’s the very last entry in the list of advertised kex algorithms by default.

Depending on the outcome of this discussion, I would be happy to consider disabling both algorithms by default. I don’t see a reason in most cases to prefer them over other more widely implemented kex algorithms. However, I’d probably leave them available just in case someone wanted to use them.

One scenario which comes to mind where these algorithms could provide a benefit is precisely in the case which led to this thread suggesting we disable them, where someone might want the ability to passively monitor a stream and compute the session key when given the RSA private key. This is not possible (by design) with other kex algorithms without becoming an active man-in-the-middle, but it could be done passively with these RSA-based kex algorithms. I know such tools exist for TLS, but I don’t know if anyone has built something like that for SSH.
-- 
Ron Frederick
ronf@timeheart.net