Subject: Re: SSH v3?

From: [email-masked] (Niels Möller)
Date: Tue, 01 Dec 2015 12:51:31 +0100

denis bider <[email-masked]> writes:

> SSHv3 is based on UDP, not TCP.

Why??? To me, a reliable byte stream as provided by tcp seems like a
building block fitting ssh needs pretty well.

If you want to do that, and support filetransfers or anything else with
the potential to use significant bandwidth, and get it blessed by ietf,
you'd have to implement your own congestion control.

Not that I have anything against congestion control work in general. I
have even given in to the temptation and designed my own, during my phd
studies. See https://www.lysator.liu.se/~nisse/network-book/. But I
don't think this is the right place for congestion control work.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: denis bider <[email-masked]>
Date: Tue, 1 Dec 2015 10:33:08 +0000

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 <[email-masked]> , 12/1/2015 10:01 AM:
Very much agreed.

Here's my wish:

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 ; [email-masked] 
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

---

From: denis bider <[email-masked]>
Date: Tue, 1 Dec 2015 10:10:03 +0000

Very much agreed.

Here's my wish:

----- Original Message -----
From: Damien Miller 
Sent: Sunday, November 29, 2015 05:48
To: Simon Tatham 
Cc: Niels Möller ; Simon Josefsson ; [email-masked] 
Subject: Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH)

-d

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 5 Dec 2015 23:30:59 +0000

>Do you guys want to work on this?

Argh, no!  Look over to the TLS WG for the train wreck that "TLS 1.3" has
turned into, incorporating every hipster algorithm and pet idea from everyone
on the mailing list.  Not only is it no longer "TLS 1.anything", it barely
qualifies as TLS 2.0, more like a completely new protocol.  It's going to end
up in the weird parallel existence that IPv4/v6 have been stuck in for the
past 15 years, and that HTTP4Google, a.k.a. HTTP 2.0, will be in for the
indefinite future.

If you really want to design a new protocol, you can contribute to the TLS
"1.3" clusterfsck :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Dec 2015 14:07:21 +0000

Stephen Farrell <[email-masked]> writes:

>my belief is that you and maybe one or two others share that opinion about
>TLS1.3

Oh, it's quite a lot more than "one or two others".  Most of them have given
up contributing to the TLS discussion though, so it's not very visible outside
of private email.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Dec 2015 13:53:19 +0000

Hi Peter,

On 05/12/15 23:30, Peter Gutmann wrote:
>  train wreck that "TLS 1.3"

FWIW, my belief is that you and maybe one or two others
share that opinion about TLS1.3. Many people are working
on it, I assume, on the basis that they want it to be widely
deployed. We should start to know whether TLS1.3 will see
widespread deployment in about a year or so and will be
able to reach sensible conclusions about that in maybe 3
or 4 years. But I guess your crystal ball is better than
mine and you know the answer already;-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Dec 2015 14:14:52 +0000

> up contributing to the TLS discussion though, so it's not very visible outside

Could be, but we'll not know for some time as I said. (It's also
interesting that about every new or major change in the IETF seems
to see that same point made, but such is life.)

S.