Re: [Curdle] Time for SSH3?

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 20 December 2023 11:18 UTC

Return-Path: <ilariliusvaara@welho.com>
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 718C6C04B449; Wed, 20 Dec 2023 03:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjzoVzfkRdb4; Wed, 20 Dec 2023 03:18:47 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9A7C04B444; Wed, 20 Dec 2023 03:18:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5DB3143D82; Wed, 20 Dec 2023 13:18:42 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id TOJ_bELjf85U; Wed, 20 Dec 2023 13:18:42 +0200 (EET)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0069072; Wed, 20 Dec 2023 13:18:39 +0200 (EET)
Date: Wed, 20 Dec 2023 13:18:39 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: saag <saag@ietf.org>, "curdle@ietf.org" <curdle@ietf.org>
Message-ID: <ZYLNjy03SG060_27@LK-Perkele-VII2.locald>
References: <GVXPR07MB96789816DE49A02D46AC25628996A@GVXPR07MB9678.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <GVXPR07MB96789816DE49A02D46AC25628996A@GVXPR07MB9678.eurprd07.prod.outlook.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/LvkFwJDEzQnGbuSZ0dIDOkoYCHs>
Subject: Re: [Curdle] Time for SSH3?
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 20 Dec 2023 11:18:51 -0000

On Wed, Dec 20, 2023 at 10:36:26AM +0000, John Mattsson wrote:
> Hi,
> 
> I strongly think the right future for SSH is to not do more patching
> and instead move to SSH3 build on top of QUIC. One such proposal was
> recently published on arXiv.
> 
> https://arxiv.org/pdf/2312.08396.pdf

That is not built on top of QUIC, it is built on top of HTTP/3.

And I find what proposal does with authentication scary:

- Use of JWTs for key authentication (really core mode).
- Offhand remarks about using OpenID Connect without any consideration
  on possible hidden landmines.
- Not supporting SSH certificates, there are fair amount of places that
  do use those (and no, those are not X.509).
- And I think some are using GSS-API too... Is that all just Kerberos,
  or is there also something else? Might be too painful to support tho.
- Using WebPKI certificates for server authentication.
- (there might be more, I only skimmed the paper.)


Then a major pain point with SSH2 is lack of capability to route
connections, forcing bad hacks with custom ports and port forwarding or
else wasting (valuable v4) IP addresses. QUIC does not solve this
problem, because it is hostile to intermediates, even ones that just
route encrypted connections (at least without severe restrictions on
what features of QUIC are allowed).




-Ilari