Re: Authenticated cipher modes

["Sara Golemon" <ietf-secsh%libssh2.org@localhost>]

As a more general solution to this problem, how about an ability to
renegotiate methods?  If the client notices that there's a common cipher
available that allows for data integrity, it can send a new KEXINIT
requesting just that cipher and a mac of 'none'.  The server could then
respond with it's own KEXINIT which agrees with that request, or perhaps
another response rejecting the renegotiation (a KEXINIT with empty methods
would probably suffice for an explicit rejection).  If the server never
sends a KEXINIT in response then it can just be assumed by the client that
renegotiation is not supported.

This way, not only is the specific case being discussed covered, but so are
other edge cases (perhaps a session wants compression off initially--for an
interactive terminal-- Then on later for a large file transfer).

As to implementation specifics, I'd see a key exchange following the
KEXreINIT being reasonable, but the session_id should remain the same (as
with other key re-exchanges).  If that's just too wasteful, maybe one of the
reserved bits in the KEXINIT packet can be used to suppress key re-exchange.

-Sara