Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt

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

   On Tue, Jun 24, 2003 at 08:14:47PM -0400, Joel N. Weber II wrote:
   > > I have thought that the gss keyex spec should allow the server to send
   > > its public host keys (as opposed to one public host key).
   > 
   > Do you have a reasonable way to implement this that doesn't break
   > interoperability?  Are there implementations in the wild that send
   > the host's public key?

   No, and I don't know.  Anyone else?

I think in the long run it would be useful for KEX_MSG_KEXINIT to
support negotiating additional features by adding more strings to the
end, with each string having a tag indicating the name of the feature
that string is negotiating.  This would allow you to provide an
alternate list of host key algorithms and key exchange algorithms that
would use a new negotiation algorithm, for example, as well as
negotiating the format of SSH_MSG_KEXGSS_HOSTKEY as to whether it
contains multiple host keys.  (I'm not convinced we should have that
multiple host key support, but if the protocol doesn't allow it to be
negotiated in an interoperable fashion when someone wants to add the
feature late in the game, it's somewhat poorly designed.)
Alternatively, there could be a seprate field for negotiating which
host key algorithm to use for the key sent with
SSH_MSG_KEXGSS_HOSTKEY.

The last field of KEX_MSG_KEXINIT is

     uint32    0 (reserved for future extension)

with no real explaination of how this should be used, as far as I can tell.

It looks to me like openssh-3.6.1p2 prints the reserved value with a
call to debug2 and otherwise ignores it, and will probably ignore
anything that appears after that field.  I have no idea what other
implementations will do if there's extra data after that reserved
value.

I bet if just adding strings at the end of KEX_MSG_KEXINIT would cause
real or potential problems, defining KEX_MSG_KEXINIT2 for additional
strings when both the client and server send 1 as the reserved value
would be likely to allow this to be extended without breaking
interoperability, and would be a far better idea than changing the
protocol version to 2.1.