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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Tim Polk <tim.polk%nist.gov@localhost> writes:

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

I have tried to review most of this lengthy discussion, and after some
thinking, my conclusion is that optionally having unencrypted length
fields is a bad idea.

There seem to be two arguments for clear-text lengths:

1. "I never liked the encrypted lengths, I think the TLS protocol
   design is better".

2. It causes additional complexity when implementing AEAD.

I don't find (1) convincing. I'd prefer not to make design changes of
this type at this time, unless there's some really, really good
reason. I'd not be surprised if there are some applications that rely
on the ssh protocol feature that message lengths are encrypted, and
are weakened if we change this. (I'd still appreciate to hear more
details on what security problems others see with encrypted length
fields, though).

I find (2) extremely unconvincing, since the proposed solutions are
additional levels of negotiation which adds a lot more complexity than
it removes. I strongly dislike having several options for how the
transport layer should work, I do *not* want to have that extra
complexity at this level. One of the options will inevitably be less
well-tested and more buggy than the other.

I'd like to propose the following guide-lines for using algorithms in
the AEAD-class with ssh:

1. The algorithm is specified as an encryption algorithm in the
   kexinit message. The mac should be set to "none" (or must? If we
   allow other values, that should mean that some other MAC is used in
   addition to the AEAD, which causes no big problem in principle but
   it seems to be of limited usefulness.

   (There are some details left to specify on exactly how this should
   interact with algorithm selection, since there are additional
   dependencies. You want to be able to ask for (aead, none) with a
   fallback to (3des-cbc, hmac), without risk of ending up with (3des-cbc,
   none). Maybe it's easier to say that if an AEAD-algorithm is chosen
   for encryption, the lists of mac algorithms (for that direction)
   are ignored).

2. The first block of each message is encrypted using a separately
   keyed cipher. For AES-GCM, this could be AES in counter mode. For
   proper authentication, the clear text for this block is included in
   the "associated data" for AEAD, together with the implicit sequence
   number, and any other context data that needs authentication. (A
   slight elaboration of Damien Miller's idea).

   The choice for the cipher for the first block should of course be
   chosen so that it reuses the same primitives as the AEAD-algorithm
   that is used.

3. The rest of the message (as determined by the length and padding
   fields contained in the first block) holds the AEAD ciphertext.

For me, it would probably work just fine to implement AEAD so that I
can get the result for the first block before reading the rest of the
data, but the above construction avoids this requirement on the AEAD
interface, so I suspect some of you will find it cleaner.

The primary objective of this proposal is to keep things simple and
minimalistic. Does it make sense? Am I missing some complication that
must be dealt with?

Regards,
/Niels