Re: [Curdle] SSH/QUIC draft

Ilari Liusvaara <> Sat, 11 July 2020 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92A173A1227 for <>; Sat, 11 Jul 2020 12:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FbwrcAFSUOZx for <>; Sat, 11 Jul 2020 12:35:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 964C83A1226 for <>; Sat, 11 Jul 2020 12:35:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 485F815C5E; Sat, 11 Jul 2020 22:35:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id iFXfZ0bOft7j; Sat, 11 Jul 2020 22:35:27 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3A3CE7A; Sat, 11 Jul 2020 22:35:25 +0300 (EEST)
Date: Sat, 11 Jul 2020 22:35:24 +0300
From: Ilari Liusvaara <>
To: denis bider <>
Cc: curdle <>
Message-ID: <20200711193524.GA239102@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
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: Sat, 11 Jul 2020 19:35:34 -0000

On Sat, Jul 11, 2020 at 12:50:09PM -0500, denis bider wrote:
> Hey everyone,
> With this inspiration, I wrote an SSH/QUIC spec which fixes all of the
> architectural problems I can think of in SSH from experience over the years:

Some comments:

- Section 2.1 just seems odd. Either one should run SSH over QUIC on
  separate port, or use ALPN to demultiplex it from other QUIC
- I do not see what would prevent attacker from passively listening
  for legimate connection and then mounting dictionary attack
  against obfustication code to discover it.
- I think HTTP/3 uses 1200 bytes instead of 1400 bytes as padding
  target (which is within IPv6 MinMTU, but considerably above IPv4
- Why is there key exchange stuff? One should have TLS do the key
  exchange and then extract any needed keys.
- Then the overall session ID should be also extracted from TLS.
- I presume server authentication should be done using the TLS
  server certificate. All of RSA, ECDSA and EdDSA (Ed25519/Ed448)
  keys (including raw) are supported.
- For client authentication, one probably should use SSH-layer
  mechanisms, due to some limitations of TLS-layer ones (extract nonces
  or shared secrets from TLS if you need them).
- For server multiplexing to work (and no server multiplexing is the
  single biggest complaint I have with all of SSH!), active migration
  MUST be disabled. As far as I can tell, handing NAT rebindings is
  still possible even with active migration off.
  * The hacks people do to deal with this are ugly to say the least.
  * Seriously, I would much rather lose NAT rebind handling than
   server multiplexing.

Looking at QUIC specifications and trying to figure out what
QUIC looks from above:

The basic data transport primitive is streams:

- Each stream can be unidirectional or bidirectional.
- Stream is of arbitrary length.
- Each stream is reliable ordered at byte granularity.
- All streams are independent.
- Stream can be opened by either peer.
- Aborts are directional (not undirectional like in TCP)!
  * Makes it possible for one side to close TX and abort RX. This is
    NOT possible in TCP.

Flow control:

- There are three flow controllers.
  * One operates on connection level, and limits the amount of aggerate
    data that can be sent on all streams together.
  * One operates on stream level, and limits data that can be sent
    on that stream.
  * One limits the number of streams that can be open at once.
  * All are independent in both directions.


- For selecting endpoint, there server name (nice for server
  multiplexing) and application layer protocol name fields.
- QUIC always does its own key exchange.
- QUIC always encrypts all application data streams.
- Server authentication with certificate or raw key is mandatory.
  RSA, ECDSA and EdDSA (Ed25519/Ed448) are all supported.
- Client authentication is optional.
  * The negotiation is really limited here!
- QUIC uses TLS, which can provode nonces and shares secrets for
  application use.