Re: Binary packet protocol rethink (was: Re: ChaCha20-Poly1305 for SSH)

[Simon Josefsson <[e-mail]>]

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

I agree.  I believe there is opportunity to deprecate all pre-AEAD
modes, if there is interest on doing that.  I believe the experience
with TLS is that no non-AEAD mode has the properties that we desire.
Generally, I believe the experience is that you cannot negotiate cipher
and MAC separately, it has to be done together.  Maybe we can draft
something together, and bring it to the curdle IETF WG, it would be in
scope of that process.

Looking at these registries:
http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-17
http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-18

I believe it would be possible to mark all as obsolete/historic, except
for a list of a few known good combinations that we can actually
recommend. As far as I can tell that list would include:

aes128-ctr
aes256-ctr
chacha20-poly1305 (whatever that turns out to be)
umac-* (same here..)
hmac-sha1 (for older ciphers only?)
hmac-sha2-256 (for older ciphers only?)

Any others?

I'm not sure what to make of the RFC 5647 AES-GCM mode.  Nobody seems
to implement that.

/Simon