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

[Tero Kivinen <kivinen%iki.fi@localhost>]

Nicolas Williams writes:
> On Wed, Apr 08, 2009 at 10:57:49PM -0500, Nicolas Williams wrote:
> > On Thu, Apr 09, 2009 at 03:51:35PM +1200, Peter Gutmann wrote:
> > > Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:
> > > 
> > > >[So far the only extensibility mechanisms that we have at that point in the
> > > >protocol are: new protocol version number (not going to happen) and magic
> > > >algorithm names (which have been used successfully).]
> > > 
> > > ... and the completely unused 32-bit flags field in the first message, which I
> > > mentioned previously :-).
> > 
> > This:
> > 
> >       uint32       0 (reserved for future extension)
> > 
> > ?
> > 
> > Yes, that could be used too.
> 
> Er, actually, I'm not sure.  It depends on what implementations do with
> it now when it's not set to 0.  Hmmm, what does the spec say to do about
> that field?  Sadly: nothing, at least not in section 7.1.
> 
> That probably means that we can't use that field.

Not sure about the Secure shell implementations, but on the IKEv1
implementations I have seen that security people have usually not been
very liberal what they accept unless that is explicitly spelled out in
the RFC, i.e. I would expect there are implementations which will fail
negotiation if the reserved field is not zero (yes, those could be
considered as broken implementations).

Another possibility to negotiate this per cipher is to encode it as
part of the cipher name, i.e. define in this AES-GCM document (or make
it separate document, so other AEAD ciphers can refer it independently
to the AES-GCM) that if the cipher name for example starts with "*"
(ASCII-character 052, 42, 0x2a) then cipher uses clear text length
field.

In that case implementations can either just check the name
completely, i.e. know that "*aead-aes-128-gcm" and "*aead-aes-256-gcm"
ciphes use this format, or they can simply see that if first character
of the cipher is "*" then it uses this new format and check if the
rest of the cipher name is valid, and use that as real cipher. That
would allow implementations ability to propose cipher lists like
"aes256-cbc,*aes256-cbc,*aead-aes-256-gcm" if needed.

The question is do people really want to use old ciphers also with
clear text length field?

If so then this would allow easy configuration to support those for
even old implementations with minimal changes, and backward
compatibility with old versions (I do not think we can find a secure
shell implementation which breaks when it sees unknown cipher name in
cipher lists).

Anyways if we go to the clear text packet length, the security
considerations section of the document describing it needs to give
more information, as RFC4251 (SSH-Arch) does not cover that case.
-- 
kivinen%iki.fi@localhost