Re: [Curdle] SSH/QUIC draft

denis bider <> Sun, 12 July 2020 03:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6D283A09DB for <>; Sat, 11 Jul 2020 20:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2p1rJxWs11v for <>; Sat, 11 Jul 2020 20:44:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D403A0BF3 for <>; Sat, 11 Jul 2020 20:44:01 -0700 (PDT)
Received: by with SMTP id x83so8171270oif.10 for <>; Sat, 11 Jul 2020 20:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2x/Uf22yL4NVob0gJ/QmdgEDkqgQEkFSpvuJnGJNy+c=; b=KMP3CtTXl+6aNTHdililHHylgwOrd0jTZxtimcRBRH+pc/hgNFNSakCRrAGzgPAsVG IG3bMkbKJKbZuwWvwT+5UaAKIUgNJw174bd2UGfj6ocIG1TzpsYjLtePa6i9FjcjwgRT ItxBWGyJA7+yB9BaGExUIvFhnLnnOESXf6ffr9PzQuacmweyy0gQJVSp1X+9gH/MDuEA vf9EnI3k5oqhYZ+t6D0VNkoPnUSRLstXvw1mATf2LJyegouD6j4YHmWYtlmXhloQXIde 0ZpaJj0h1q/aS4uau6qUnwvZU3nP4s4Ojo3SNP9+z9/cIBv/8IXTzjj3wyQ3pxcURv6Z FT+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2x/Uf22yL4NVob0gJ/QmdgEDkqgQEkFSpvuJnGJNy+c=; b=e/4NsL3ZFFHk3914SP67pOHmxZ9ZOQjbMAMx9OG63HpPEPvc8Cs8wMWgFAQM4dT0a4 14QkzXr2dV06uZ9EophG+Kp1ufKtHLPZ85pRndBp4zL0JnY4fX0Wb8ryxG8Rw+OTaD64 +BY10Xfc47HpRmcmo4MV18J+lNDi3mtpvg+sp5S4EW+wiU+AQnj05JaY3LDViLSP4kYy sNzNLLSfzEGOU1sF6u+CiRcnZJz8kWmC/DzXE/TFnBd58PJRrqmKue6bMkOSUwrZNQCT OMMl1IUf2RhWFREa2BnHTnUneTtRCZw0LTgQklPoom7pIIeDecf8FuAseBRHQ5WnbFdn 6Hyw==
X-Gm-Message-State: AOAM531n11fx6O+Awl0XhfXtshNy5Kb4DU7PElhk1AMMI6AJVDjYPVU6 zqDi4R6PzBcQ7Sy395iJ/cz7TAqurXtCAMmw5jw=
X-Google-Smtp-Source: ABdhPJxFI+g1abwHgtceJwlU0nl9AwEwiziYk+YJg6ttvzymWGH/FXXgypi0DaKcx02a26fRXff+xdQVIJJnxF/4N4s=
X-Received: by 2002:aca:b743:: with SMTP id h64mr9892726oif.88.1594525441102; Sat, 11 Jul 2020 20:44:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: denis bider <>
Date: Sat, 11 Jul 2020 22:43:49 -0500
Message-ID: <>
To: Peter Gutmann <>
Cc: curdle <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000080959605aa36620d"
Archived-At: <>
Subject: Re: [Curdle] SSH/QUIC draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jul 2020 03:44:10 -0000

That's one of the problems and it's solved in SSH/TCP for single-channel
connections by implementing "no-flow-control", as you note. It's not solved
for multi-channel connections, and it leaves several other problems of
SSH/TCP unsolved.

The SSH/QUIC draft solves the flow control problem in the general case, for
multi-channel connections, and solves the other several problems of

I have just uploaded a new version (-04) with improvements inspired by
feedback from Ilari.


On Sat, Jul 11, 2020 at 10:23 PM Peter Gutmann <>

> denis bider <> writes:
> >For at least 7 years now, I've been pondering that TCP is a poor transport
> >for SSH and should be replaced by UDP.
> The problem isn't TCP, it's SSH, specifically SSH's terrible flow control
> a.k.a. the SSH performance handbrake, which (for SFTP) layers TCP over TCP
> over TCP.  The solution isn't to run it over a protocol that hides one
> layer
> of the handbrake but to fix SSH's flow control problems.
> And yes, I know that in theory a fix is possible if every implementation
> everywhere is very carefully implemented and tuned to perform exactly the
> same
> precise dance to avoid the handbrake, but better would be to fix the
> underlying problem.
> In my case for example I just ignore the flow control/handbrake, a.k.a.
> "no-
> flow-control" if you can find anything that supports that, and get pretty
> much
> line speed on data transfers.  OK, this is a bit antisocial, but it avoids
> having to answer "why do I get an order-of-magnitude performance drop with
> vs.TLS when the same algorithms are used" questions.
> Peter.