Re: SSH v3?

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Just going briefly through the EST spec, the way I left it last year, I notice several things I would prefer to change:

- I am no longer as much adverse against IETF standardization, as long as someone else beside me is willing to jump through the hoops.

- I have a better variable-length integer encoding format now, which I would prefer to use instead of the one presented.

- It might be necessary to change EST_HASH to use the full 32 bytes of the HMAC-SHA2-256 construction, instead of just the first 20 bytes.

- In the private key format, I'd replace PBKDF2 with Argon2, recent winner of the password hashing competition:
  https://password-hashing.net/

- Folks here would probably want to standardize "eddsa" instead of ECDSA over secp256k1.

- Then again, folks who need to support FIPS would prefer ECDSA. Free high quality implementations of secp256k1 are available:
  https://github.com/bitcoin/secp256k1

There are probably other tweaks I would make. Currently, the spec is posted as-is, the way I left it before I shelved it.

Comments welcome, if you guys want to do this.

denis bider <ietf-ssh3%denisbider.com@localhost> , 12/1/2015 10:01 AM:

Very much agreed.

Here's my wish:

SSHv3 is based on UDP, not TCP.

I actually have a whole spec for that ready-made, which includes things like negotiating encryption + authentication as one thing...

Heck, if you guys want to work on that, here's the spec:

https://www.bitvise.com/files/EfficientSecureTransport.pdf

The initial defined algorithms are kinda arbitrary and trivial to substitute. I was going to put in Ed25519 and AES GCM, but I didn't have access to that at the time, so I put in something I had access to.

I actually have a platform-independent C++ implementation, too.... Complete, just never tested.

Do you guys want to work on this?


----- Original Message -----
From: Damien Miller
Sent: Sunday, November 29, 2015 05:48
To: Simon Tatham
Cc: Niels Möller ; Simon Josefsson ; ietf-ssh%netbsd.org@localhost
Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH)

While we're dropping wishlist items for SSH v.3, here's one of mine:

Key exchange negotiates an AEAD rather than a cipher and a MAC
separately, and does so from a greatly trimmed set of options. E.g.
AES-GCM, chacha20+poly1305 and an AES-CTR+HMAC mode.

IMO the AEAD primitive is the right metaphor for the security properties
of the SSH transport protocol. Removing the large cartesian product of
ciphers x MACs will make testing faster and binaries smaller too.

-d