Let me start off by saying one of my principal goals is to keep
the design of sesch-aes-gcm as clean and elegant as possible. A
clean design is far more likely to be implemented properly.
From a purely cryptographic point of view, leaving the
length field in the clear is the more elegant solution. But
we are not starting with a blank slate, we are trying
to fit this into the existing secsh architecture.
I see three questions:
1) Does encrypting the packet length effectively mask the length
of the binary packets?
2) Does leaving the length field unencrypted lead serious
implementation issues?
3) Does encrypting the length field seriously complicate the
security analysis of secsh applications using an AEAD mode of
operation?
On question #1, I would argue that the encryption of the packet length
is largely ineffectual. Currently secsh encrypts the entire binary
packet. In theory this results in a featureless octet stream flowing
between the originator and the recipient, but in practice the dataflow
will come in bursts, with the length of each burst strongly correlated
to the length of the underlying binary packets. Use of secsh's random
padding mechanism and SSH_MSG_IGNORE messages would seem to be much more
effective in masking the packet lengths.
(For sake of clarity, I'd like to take this opportunity to remind
everyone that even if the length field is unencrypted, it will still be cryptographically authenticated under GCM's GMAC.)
On question #3, sequestering the contents of the binary packet until
the MAC has been verified clearly simplifies the security analysis
of AEAD based systems. Allowing a partial decryption to recover the
packet length weakens this constraint and complicates the security
analysis. I suspect this is an minor annoyance rather than a serious
flaw.
Question #2 seems to be raising the most issues. Dealing with an unencrypted
length field is definitely an annoyance, but several mechanisms have been
proposed to allow this.
My interests here are quite parochial - I'd be more than happy if we could
agree that any algorithm with the string "aead" in its
name does not encrypt the length field.