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

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

Hello,

> It sounds like AEAD is sufficiently different that it 
> _requires_ modifying the transport layer for sensible implementation.

This is true for the generic case of AEAD-*, but not true for AEAD-AES-GCM.  AEAD-AES-GCM works fine per draft.  I want to stress it can be made to work, including the MAC --- AEAD-AES-GMAC.  AEAD-AES-GCM using same cryptographic AES-GCM used by our TLS 1.2 implementation was reused with SSH.  The algorithm was quite simple to adopt.  I spent some extra effort to verify that message chunks were not an issue (mainly due to what I had read online this being an issue).  I was not the author of our AES-GCM implementation, and I didn't need to consult him --- it was fairly effortless to integrate.  

I'd like to see Suite B related drafts move forward.  IMO - We're down to one small issue on each that are blocking final consensus.  I am fine with adding support for clear text length field, if this means we can move to final RFC --- although I personally don't believe it's necessary work at this time to support AEAD-AES-GCM.  

Btw There has been a couple of important SSH drafts that have stalled, which is a shame.  And which I would like to pick up and resurrect.  

Thank you,

James

-----Original Message-----
From: denis bider (Bitvise) [mailto:ietf-ssh2%denisbider.com@localhost] 
Sent: Wednesday, April 15, 2009 6:29 AM
To: James Blaisdell; Niels Möller; 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
Subject: Re: applying AES-GCM to secure shell: proposed "tweak"

I've been seeing this argument enough that I need to comment on it:

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

- We have TWO fully asynchronous SSH implementations, and the encrypted 
length field has not been an implementation problem for either of them.

- Introducing a new way of sending length unencrypted is not going to 
relieve programmers of the burden of implementing the encrypted length. If 
anything, it's going to add a NEW burden of having to support two ways of 
sending and receiving the length, encrypted and unencrypted.

- The one problem I know of with sending the length encrypted is that it has 
facilitated a plaintext discovery attack when used with CBC. The proper 
response to that is to (1) prefer CTR mode, and (2) implement length 
decoding in a way that defeats the attack.

That being said: I have no problem with the AEAD implementation doing 
whatever it wants, as long as implementations that don't want to use AEAD 
are unaffected. It sounds like AEAD is sufficiently different that it 
_requires_ modifying the transport layer for sensible implementation. At the 
very least, for example, it needs to introduce a dependency that will 
implicitly turn off the MAC algorithm when AEAD is used.

If I were implementing AEAD, however, I would also worry about any possible 
implementations that might be relying on the SSH packet boundary not being 
obviously disclosed, and would worry about AEAD's compatibility with such 
applications. This seems to gesture that continuing to implement an 
encrypted payload field may be a good idea even with AEAD.

denis