I've been seeing this argument enough that I need to comment on it:
The encrypted length field has been a pain in the past, especiallyfor async implementations like mine, but I have lived with it fine for last few years.
- We have TWO fully asynchronous SSH implementations, and the encrypted length field has not been an implementation problem for either of them.
- Introducing a new way of sending length unencrypted is not going to relieve programmers of the burden of implementing the encrypted length. If anything, it's going to add a NEW burden of having to support two ways of sending and receiving the length, encrypted and unencrypted.
- The one problem I know of with sending the length encrypted is that it has facilitated a plaintext discovery attack when used with CBC. The proper response to that is to (1) prefer CTR mode, and (2) implement length decoding in a way that defeats the attack.
That being said: I have no problem with the AEAD implementation doing whatever it wants, as long as implementations that don't want to use AEAD are unaffected. It sounds like AEAD is sufficiently different that it _requires_ modifying the transport layer for sensible implementation. At the very least, for example, it needs to introduce a dependency that will implicitly turn off the MAC algorithm when AEAD is used.
If I were implementing AEAD, however, I would also worry about any possible implementations that might be relying on the SSH packet boundary not being obviously disclosed, and would worry about AEAD's compatibility with such applications. This seems to gesture that continuing to implement an encrypted payload field may be a good idea even with AEAD.
denis