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

[James Blaisdell <JBlaisdell%mocana.com@localhost>]

Hello,

I can live with cleartext length field or encrypted length field.  I have implemented AES-GCM as the draft stands now, so I know it's technically possible.  It has been suggested that some AES-GCM implementations must process the message as a single block of data --- a black box.  I don't know what hardware offload (proprietary?) that is unable to process AES-GCM in a chunk manner; Cavium can process in chunks.  I suppose at some point in the future an AEAD-* method will not be able to process the message in chunks, but this draft is for AEAD-AES-GCM.  Are we trying to future proof something that may never happen?  Even so, I would imagine it could dealt with at that time --- there will be an inconsistency now or future.  

I do agree sending the length field in the clear will cause some headaches at a lowest level, since a new in/out method will need to be written and tested.  However, I don't see the issues around NEWKEY some have suggested, but perhaps that implementation specific.  The encrypted length field has been a pain in the past, especially for async implementations like mine, but I have lived with it fine for last few years.  

The only issue I have any energy around are suggestions for fallback approaches or no-MAC; similar approaches have been suggested for SSH-ECDSA.  These approaches create a great deal of work and break the current protocol model.  

Thank you,

James

-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Niels Möller
Sent: Wednesday, April 15, 2009 1:57 AM
To: Tim Polk
Cc: ietf-ssh%netbsd.org@localhost; Tero Kivinen; Bill Sommerfeld; Chris Lonvick; ylo%ssh.com@localhost; Igoe, Kevin M.; Jerome A. Solinas; <Pasi.Eronen%nokia.com@localhost> Eronen
Subject: Re: applying AES-GCM to secure shell: proposed "tweak"

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