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

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

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

That's not the only metric that matters.

> We don't need no stinking generality here :) given that we weren't
> given it to begin with :)

That's why we're trying to design a clean mechanism that provides it,
rather than throwing in a kludge for this case, another kludge for next
case, and pretty soon you're shoehorning protocol version numbers into
the authentication username string or some such horror.

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

Why?  Why not just have the gss kex define its kex-method-specific
messages so as to permit multiple back-and-forths, retrying as much as
necessary to find something suitable?

Actually, perhaps the best way to answer that would be to sketch the
semantics for the retryable-kex bit you'd like to define; then I could
probably see what the issue is (or suggest a way that doesn't break
interoperability that badly, using existing facilities).

/~\ 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