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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I agree.  I see no reason to deviate from using alg names for this
> sort of negotiation.

For this particular case?

If you're proposing to use it with all, or even a large subset of,
existing ciphers, I do: it avoids the cross-product problem.  One
option like this doubles the number of ciphers offered  Each additional
such binary option doubles the list size again, and an option with more
than two settings multiplies it more; pretty soon you're up to offering
dozens of names for each cipher supported.  THe cross product problem
is bad enough already with things like operating modes (_cbc, _ctr) and
key sizes (aes{128,192,256}_*).

If you're proposing it as a particular encryption algorithm which
happens to "encrypt" the length trivially, I agree, it should be just
another encryption algorithm as far as the protocol goes.

In general?  I disagree.  There are many things which could reasonably
be negotiated as options using a mechanism like this, and they don't
all make sense as GLOBAL_REQUESTs.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B