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

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

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

That was my first thought, to restrict it to (for this case) use during
kex.  I was unable to come up with a way to do that that I was sure
didn't have nasty races or deadlocks - especially since the number of
packets required for kex is variable.

Anyway, SSH_MSG_OPTION as I defined it is not restricted to things
suitable for use during kex.  But if you have an option that you want
to negotiate there, you can define it to be an error at any other time.

>> I propose the option name "cleartext-packet-lengths".  [...]
> 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"?

First, it rqeuires that it be done in both directions or neither, which
is very un-ssh.  Everything else about the connection (encryption, MAC,
etc) is negotiated separately in each direction.

Second, it doesn't define the point at which these messages are sent,
nor the point at which unencrypted packet lengths come into use.  That
can't work.

Third, if one side tries to turn it on and the other doesn't, the
connection is left in an uncertain half-done state, where the other
side may finally mention it and clarify everything, but what happens if
that never happens?

If you have something better to suggest, go ahead.  Just make sure it's
precise enough to implement; most of the verbiage that put you off was
precision and error handling, not the core of the spec.  I was just
scribbling something down; it's possible, even likely, it could be done
much better.

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