Re: applying AES-GCM to secure shell: proposed "tweak"

[Damien Miller <[e-mail]>]

On Wed, 8 Apr 2009, Tim Polk wrote:

> Folks,
> 
> The IESG is currently considering publication of draft-igoe-secsh-aes-
> gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer
> Protocol", as an Informational RFC.  The draft specifies the
> application of the Authenticated Encryption with Associated Data
> (AEAD) block cipher mode AES Galois/Counter Mode to provide both
> confidentiality and data integrity for SSH.  (See RFC 5116, "An
> Interface and Algorithms for Authenticated Encryption", for a general
> look at AEAD algorithms and NIST Special Publication 800-38D for the
> specification of the GCM mode; see URLs below.)
> 
> The draft was designed to minimize the changes to RFC 4253 (the SSH
> Transport Layer Protocol), so it encrypts the whole SSH binary packet,
> including the packet_length field.
> 
> However, AEAD decryption as defined in both RFC 5116 and SP 800-38D
> takes the ciphertext as input, and returns either (1) the plaintext if
> the authentication succeeds or (2) failure. The ciphertext here is an
> octet string of known length, not an ubounded stream.
> 
> Since the packet_length field is also encrypted, SSH cannot determine
> the ciphertext boundary before passing the data to AEAD decryption.
> (This differs from current SSH encryption modes where the data is
> first decrypted, then the packet length field is parsed, and finally
> the MAC is verified.)
> 
> Two solutions have been proposed: (1) explicitly allowing "partial
> decryption" so that an implementation can recover the packet_length
> without authenticating the data; or (2) sending the packet_length
> unencrypted so that it is always available.

another option, would be encrypting the length field with an
independently-keyed cipher, but I doubt that it is worth it.

I'd agree that simply leaving the length fields unencrypted would
be best, but the security considerations should mention the need to
use padding to avoid revealing secrets, especially for password
userauth.

Some general comments on the draft:

First, why GCM? Some rationale would be nice.

4.1 Key exchange implies modification to the matching rules, but doesn't
IMO sufficiently spell out exactly how matching should occur when the
GCM method appears in various positions of the client and server's lists.

5.1/5.2 - The suggested algorithm names are structurally different to
the other algorithm identifiers used in SSH. In particular, I don't see
any need for the "-ssh" to appear in the algorithm name as the cipher
has not been modified in any substantial way. Why not just "aes128-gcm"
or "aes128-gcm-aead" if you wanted to be particularly verbose?

-d