[Ssh] Re: draft-miller-sshm-hostkey-update-00

"Joseph S. Testa II" <jtesta@positronsecurity.com> Fri, 29 August 2025 12:25 UTC

Return-Path: <jtesta@positronsecurity.com>
X-Original-To: ssh@mail2.ietf.org
Delivered-To: ssh@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A12F75A92147 for <ssh@mail2.ietf.org>; Fri, 29 Aug 2025 05:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=positronsecurity.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elCXHepMRtGB for <ssh@mail2.ietf.org>; Fri, 29 Aug 2025 05:25:12 -0700 (PDT)
Received: from electron.positronsecurity.com (electron.positronsecurity.com [IPv6:2600:1f18:420a:b500:bc4:c9c6:1d6:e3e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5671C5A92142 for <ssh@ietf.org>; Fri, 29 Aug 2025 05:25:12 -0700 (PDT)
Received: from lol (syn-074-074-134-088.res.spectrum.com [74.74.134.88]) by electron.positronsecurity.com (Postfix) with ESMTPSA id ED3C23ED64; Fri, 29 Aug 2025 12:25:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=positronsecurity.com; s=default; t=1756470312; bh=R3dJfHXkGAncdYvy6K9EFBX7q7CkmW6q9PCU1Zy8cyk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=FKDIhc1/z47sSCkvRQcb+Y4y1Hqnp3aAcfJ/OfaJZ4jmGeHHroqpQrfzrtHQqLL1q DvFLYHJPZbYBXDKiSvrIE8Jjo1Al2o/B6mKVJJCgpJxH00nsbZKFQ7SEaWBkkWkKTl pnmqH6VjJX0DRBMndhOmCtRuw6odKlNEEhCGSRJmhOVia442OWPO44neLDcGrqNjIB 5DWPHBrKpH1qjhh4y1bdaVh6G684k5uj/yA7jbNq3I4T3GD2CrC9WjRMT1wnTsYIhE xufS1VKcnEcDG146R0wf08cK95dcZFbavNmaJxA/5hzMmg9eW11oMAMZ/c+GIlAIt/ 24VTFsmfwmyiw==
Message-ID: <1d178032c749cb389ac12f14bdd6a81f12b2bf50.camel@positronsecurity.com>
From: "Joseph S. Testa II" <jtesta@positronsecurity.com>
To: Damien Miller <djm@mindrot.org>
Date: Fri, 29 Aug 2025 08:25:11 -0400
In-Reply-To: <86d7da6e-8672-562c-39fd-d93da33c7d8f@mindrot.org>
References: <2d9b9e04-97cf-55a9-9fb0-0b9d1a087aa2@mindrot.org> <MN2PR17MB4031A3BFD3B4F5DE209901CDCD33A@MN2PR17MB4031.namprd17.prod.outlook.com> <86d7da6e-8672-562c-39fd-d93da33c7d8f@mindrot.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5-0ubuntu1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID-Hash: HOSZWRKVLKGQSK7L67MXKOA5IKW7C674
X-Message-ID-Hash: HOSZWRKVLKGQSK7L67MXKOA5IKW7C674
X-MailFrom: jtesta@positronsecurity.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "ssh@ietf.org" <ssh@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ssh] Re: draft-miller-sshm-hostkey-update-00
List-Id: "The SSH mail list will allow discussions on improving aspects of the Secure Shell (SSH) protocol." <ssh.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ssh/lITOKpvWZzD7Qo_RpCjsOuWs57I>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ssh>
List-Help: <mailto:ssh-request@ietf.org?subject=help>
List-Owner: <mailto:ssh-owner@ietf.org>
List-Post: <mailto:ssh@ietf.org>
List-Subscribe: <mailto:ssh-join@ietf.org>
List-Unsubscribe: <mailto:ssh-leave@ietf.org>

In section 2.2:

> A server MUST reply to this request either with the success message
defined below or a SSH_MSG_REQUEST_FAILURE if the server (in case of
failure or unwillness to service the request).

If the server... ?

In section 5.3:

> Implementation should enforce some limit on the maximum number of
keys they will accept

If this RFC doesn't specify a concrete limit, then an effective limit
will still be set by the most popular implementation's chosen value...
and with much less discussion around what is good for everyone/all use
cases.  So perhaps we should discuss this now.

Otherwise, good draft!

  - Joe