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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Apr 08, 2009 at 09:02:00AM -0400, Tim Polk wrote:
> 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.

As you know encrypting the SSH packet length has caused us nothing but
trouble.  I recommend sending it in the clear.

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

(1) may be impossible to implement with some existing AEAD crypto APIs.
Adding AEAD crypto APIs that allow for "partial decryption" is possible,
but would add a significant wrinkle in getting this deployed.

I strongly recommend (2).  It's what all other protocols do.

There's also (3): specify two variants of this ssh cipher, one that does
not encrypt the packet length (this one would be REQUIRED) and one that
does (OPTIONAL).

We should do (3) IFF there are implementors who really need to defeat
traffic analysis and are up to the task of ensuring that, for example,
TCP window changes don't give away SSH message boundaries, and that they
use random padding and ignore messages in a way that does hide actual
ssh traffic patterns.

> The first solution requires less security analysis about SSH, but more
> analysis about the AEAD algorithm. The exposure of intermediate values
> in AES GCM would require review, and it is inconsistent with RFC
> 5116. Even if this solution is determined to be secure for AES GCM,
> this might not apply to other AEAD algorithms (where returning
> plaintext fragments before authentication may not be even possible, or
> may not be secure). In a more parochial concern, inconsistency with SP
> 800-38D means that current validation processes (i.e. NIST's FIPS
> 140-based Cryptographic Module Validation Program [CMVP]) would need
> to be revised, as well as SP 800-38D, to permit use of this protocol
> with validated modules.

Indeed, (1) is just too painful.

> The second solution (sending packet_length unencrypted) has a number
> of desirable properties: it conforms to RFC 5116 so the design should
> apply to any AEAD algorithm, and it is consistent with the algorithm
> specification (NIST SP 800-38D).  It does require a change to the
> padding calculations: since the plaintext for encryption excludes the
> packet_length, the concatenation of the 'padding length', 'payload',
> and 'random padding' MUST be a multiple of the cipher block size.
> (This modifies a requirement from Section 6 of RFC 4253.)  Since this
> calculation is algorithm specific anyway, it is hoped this would not
> be an issue. As you might have guessed, I strongly prefer this
> solution.  However, we are concerned about making such a change
> without ensuring that the security implications have been thoroughly
> reviewed.

The fact that SSHv2 encrypts the packet length has been a cause of a
significant protocol security vulnerability.  Let's kill this encrypt-
the-packet-length notion.

> So, it seems that encryption of the packet_length field would be of
> little practical use, and might lead to a false sense of security.  As
> a consequence, we hypothesize that sending packet_length in the clear
> would not negatively impact the security of the protocol.

Agreed.

> Before moving forward with this protocol using either of the proposed
> solutions, we would appreciate feedback from this mailing list.
> Questions to consider:
> 
> (1) does the exposure of the ssh packet length have significant
> security implications for ssh itself?

Not negative ones.  As you say, one may want to ensure the use of random
padding to avoid revealing, e.g., password lengths.

> (2) were applications that rely on ssh for security designed to take
> advantage of the encrypted packet length?

Not that I know of.

> (3) does the change in padding length calculation (caused by excluding
> the packet_length from the ciphertext) impose a significant impediment
> to migrating existing implementations?

The changes would all be localized to the SSHv2 implementation.  There
would be more changes to make to an SSHv2 implementation if we go with
(2), but (1) requires changes to parts of the system that an SSHv2
implementor may not be in a position to make, thus from a political
point of view (2) is clearly easier than (1).

Nico
--