Re: [Curdle] SSH/QUIC draft

[Ilari Liusvaara <[e-mail]>]

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