[F]rom what I've gathered from the list, this could, as far as the core protocol is concerned, be seen as an encryption algorithm that happens to produce ciphertext identical to the plaintext for certain parts of the data stream.I wouldn't have a problem with that, but it's not actually the case. The base protocol spec assumes that encryption algorithms have a block size, and requires that the amount of padding be chosen such that the combined size of the length, padding length, padding, and payload be a multiple of the block size.Right - with an artificial block size imposed for stream ciphers. (Actually, the wording in RFC4253 is not very good; consider what an implementer reading the "Note that the..." paragraph beginning ten or so lines into page 8 would do with a cipher using 7-byte blocks.)
I read that paragraph as normative, and having the effect that SSH cannot operate with ciphers having a block size of 3, 5, 6, or 7 bytes. If you really wanted to use such a cipher, the document describing its use with SSH would have to artificially increase the "block size" to something larger than 8 bytes.
Moving the length out of the encrypted part requires changing this behavior.Why? As far as I can see, this is so only if (a) the underlying cipher has a block size that's not a divisor of 4 bytes and (b) you insist on naïvely treating all the sent-encrypted data as a single data stream for the encryption engine.
OK, I'll grant that it's not necessary when using a stream cipher, or a block cipher with a block size of 1, 2, or 4 bytes. But I don't think there are any of the latter.
It would be very easy, for example, to use arcfour (or any other stream cipher) to encrypt all but the length. Also, I just reread section 6 of 4253, and I can't find anything that says the ciphertext from an encryption algorithm has to be the same size as the plaintext, so you could always just save the length, replace it with four random bytes, encrypt as normal, and prepend the saved length. (Decryption, of course, just throws away the four random bytes.)
I think what you're effectively suggesting here is that the transport layer pad to the "wrong" size (since the length is included but will not be encrypted), and then the encryption algorithm add extra "hidden" padding to pad it to the right length.
I think that could work, but note that the number of bytes of ciphertext must be exactly equal to four plus the "decrypted" length value, since the latter is the only indication of how many bytes the transport layer should read out of the TCP stream. There are likely implementations which expect the "decrypted" length to also be the length of the plaintext packet (not counting the packet_length and mac), which would have to change.
OTOH, I would expect support for AEAD-mode ciphers to make it necessary for the plaintext and ciphertext to be different sizes anyway, so this shouldn't be a major change.