Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Thu, Jul 17, 2003 at 03:21:39PM -0400, Joel N. Weber II wrote:
> While I have previously spewed to the list about many of these things
> as possible ways to extend the protocol and why they will work badly,
> I did so before I'd realized that we had this in the transport draft:
> 
> | 9.4 Reserved Messages
> | 
> |    An implementation MUST respond to all unrecognized messages with an
> |    SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
> |    received.  Such messages MUST be otherwise ignored.  Later protocol
> |    versions may define other meanings for these message types.
> | 
> |      byte      SSH_MSG_UNIMPLEMENTED
> |      uint32    packet sequence number of rejected message
> 
> So I see no reason why the working group can't declare that there will
> be an SSH_MSG_KEXINIT2 which has a numeric value of 22, and
> SSH_MSG_HOST_KEYS_REQ can be 23, and SSH_MSG_HOST_KEYS_REP can be 24.
> (Or we could pick other numbers.  It isn't important what the numbers
> are as long as we agree on them and nobody is using them for something
> else.)  And unless someone knows that there are buggy implementations
> out there, we can assume that ``negotiation'' will happen when
> SSH_MSG_UNIMPLEMENTED gets sent.

But, again, we have the problem that any such messages would not be
factored into the session ID, thus making downgrade attacks possible.

I'd rather either have KEXINIT extensibility semantics clarified or use
bogus alg names.

Cheers,

Nico
--