Re: Transport messages during kex

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

Jeffrey Hutzelman writes:

> On Wednesday, July 21, 2004 12:26:06 +0100 Jacob Nevins
> <jacobn+secsh%chiark.greenend.org.uk@localhost> wrote:
> 
> > Jeffrey Hutzelman writes:
> >> And what's wrong with other (not yet defined) messages in the 20-29
> >> range? Without these, it will become difficult to extend algorithm
> >> negotiation, which I know we've discussed in the past.
> >
> > In principle yes, but at this point I'd be inclined to defer resolving
> > this to such time as such extensions are actually defined.
> 
> That doesn't help.  The issue is that in order to extend the exchange in
> the future, an new peer needs to be able to send a not-yet-defined message
> to an old peer and get SSH_MSG_UNIMPLEMENTED back.  In order for that to
> work, old peers must accept the not-yet-defined message and return
> SSH_MSG_UNIMPLEMENTED, rather than ignoring the not-yet-defined message or
> deciding to disconnect (either of which would appear to be OK -- we don't
> define what happens if you get a message that you MUST NOT accept).
  [snip other explanation]

OK, you've convinced me. How does the following replacement Section 7.1
paragraph for my proposal sound?:

   Once a party has sent a KEXINIT message for key exchange or
   re-exchange, until is has sent a NEWKEYS message (Section 7.3), it
   MUST NOT send any messages other than:
   o  Transport layer generic messages (1 to 19) (but SERVICE_REQUEST
      and SERVICE_ACCEPT MUST NOT be sent);
   o  Algorithm negotiation messages (20 to 29) (but further KEXINITs
      MUST NOT be sent);
   o  Key exchange method specific messages (30 to 49).
   The provisions of Section 11 apply for unrecognised messages, etc.

(the rest of my proposal is unchanged; see it in full at
<http://www.chiark.greenend.org.uk/ucgi/~jacobn/cvsweb/ssh2-kex-data.d/draft-ietf-secsh-transport-18-plus-kex-data.txt.diff?r1=1.1&r2=1.4&f=H>
or <http://tinyurl.com/4hdge>

To attempt to address Derek Fawcus' comments elsewhere: I don't believe
this precludes the future implementation of a non-blocking rekey
extension. (I'd have thought the obvious way to do that would be to
substitute a new KEXINIT_NONBLOCK in the 20-29 range for the KEXINIT
used for a re-exchange.) I don't think there's a need to leave responses
to any messages formally unspecified given the UNIMPLEMENTED mechanism.