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

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

On Fri, Apr 10, 2009 at 12:58:56AM -0400, Jeffrey Hutzelman wrote:
> --On Thursday, April 09, 2009 11:17:08 PM -0500 Nicolas Williams 
> <Nicolas.Williams%sun.com@localhost> wrote:
> 
> >On Thu, Apr 09, 2009 at 11:42:55AM -0400, Jeffrey Hutzelman wrote:
> >>No, I think the right thing is for the SSH_MSG_OPTION message itself to
> >>be  permitted at any time, and leave it to the definitions of individual
> >>options to specify when an option may be negotiated and when the results
> >>of  that negotiation take effect.
> >>
> >>[...]
> >>
> >>With regard to the negotiation itself, I think it might be cleaner to
> >>have  three separate messages:
> >
> >Surely you jest.  Why get so complicated when the much simpler
> >negotiation through alg names will do?  What value is there in this
> >complication?
> 
> - generality
> - allowing the feature to be negotiated for any algorithm, not just
>  a particular gcm algorithm, without a cross product explosion

I'd rather have a magic alg name that does this.  It's less code, a lot
less code.  We don't need no stinking generality here :) given that we
weren't given it to begin with :)

BTW, I would love to use the reserved field of KEXINIT to negotiate
retriable key exchagne (a big deal for gss keyex).

Nico
--