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

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> To negotiate new features in keyex elegantly we must either make use of
> the reserved uint32 field in the SSH_MSG_KEXINIT packet or rev the
> protocol minor version.  Making use of that reserved field without
> revving the protocol minor version is problematic because the transport
> I-D does not discuss its semantics (do we have time to fix that?  I
> guess I'd better comment on that before the last call ends).  And
> revving the protocol minor version is a non-starter at the moment and
> probably won't come to pass for quite some time.
>
> (I'm ignoring, too, the issue of how v1 vs. v2 negotiation would happen
>  if the v2 minor version is revved - let's not go there).

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.