On Fri, Apr 10, 2009 at 01:48:01AM -0400, der Mouse wrote: > > Given that key exchange is not retriable I think the best thing to do > > is to ignore [the currently-0 last field of SSH_MSG_KEXNIIT] and > > always place a zero there until we define its meaning. That will > > allow us to use it to negotiate new features when both the client and > > server advertise them (non-zero values). > > Not without breaking interoperability with existing implementations > that check that the field is zero. > > Or do you maintain that there are no such? Or that interoperability > with them doesn't matter? I find the latter severely busted and the > former unlikely, especially since the spec does not even suggest, much > less specify, behaviour for an implementation which encounters a value > for that field that it doesn't understand. I believe that we can get to a day when implementations do the right thing with that reserved field, and in the meantime there's the hated compat bug database. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.