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

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>> If we're going to make this change, could we also consider moving
>> *all* ciphers to nonencrypted lengths?  This currently requires
>> horribly complex code to process,
>
>That wasn't my experience as an implementor.  Perhaps you're trying to (ab)
>use cryptosystem interfaces not designed for that style of use?

No, just doing it properly.

>I would suggest creating new packet type for negotiating options like this.
>As a strawman:
>
>      byte         SSH_MSG_OPTION (value = 7)
>      string       option name
>      ...          option-specific data

Actually that would have been my preference as well, at the moment SSH has no
facility for interoperable extensibility beyond defining entire new message
types via (presumably) standards-track RFCs.  Having an extension mechanism
like TLS would greatly assist in introducing new features, or enhancing
existing ones.

>SSH_MSG_OPTION may be sent at any time, except that specific option
>definitions may impose additional restrictions for packets naming that
>option.

Ugh, I would restrict this to specific places, e.g. right after the KEXINIT
and and couple of other well-defined redezvous points, not at any time.  If
you allow either side to set protocol behaviour-changing options at any point
you're going to end up with a huge interop headache.

>I propose the option name "cleartext-packet-lengths".
>
>[Multi-page description of incredibly complex negotiation snipped]

Again, this is never going to work if you expect different implementations to
interoperate cleanly.  What's wrong with "if both sides send 'cleartext-
packet-lengths' then you continue with unencrypted lengths, otherwise you
don't"?

Peter.