Re: [Curdle] SSH/QUIC draft

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 11 July 2020 19:35 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 92A173A1227 for <curdle@ietfa.amsl.com>; Sat, 11 Jul 2020 12:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbwrcAFSUOZx for <curdle@ietfa.amsl.com>; Sat, 11 Jul 2020 12:35:31 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964C83A1226 for <curdle@ietf.org>; Sat, 11 Jul 2020 12:35:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 485F815C5E; Sat, 11 Jul 2020 22:35:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iFXfZ0bOft7j; Sat, 11 Jul 2020 22:35:27 +0300 (EEST)
Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (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 <ilariliusvaara@welho.com>
To: denis bider <denisbider.ietf@gmail.com>
Cc: curdle <curdle@ietf.org>
Message-ID: <20200711193524.GA239102@LK-Perkele-VII>
References: <CADPMZDDEYZ7aTv=NUY+4+BmMnN=JxFUHUwM7=SYq=EK5v_r1oA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CADPMZDDEYZ7aTv=NUY+4+BmMnN=JxFUHUwM7=SYq=EK5v_r1oA@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/JHEUWkrTKKShQQxdLdi-INk8mck>
Subject: Re: [Curdle] SSH/QUIC draft
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: 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:
> 
> https://datatracker.ietf.org/doc/draft-bider-ssh-quic/

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
  traffic.
- 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
  MinMTU).
- 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.

Encryption:

- 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.



-Ilari