Transport messages during kex (was Re: Data transfer during key re-exchange)

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

Jeffrey Hutzelman writes:
> On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins
> <jacobn+secsh%chiark.greenend.org.uk@localhost> wrote:
> 
> > At the end of Section 7.1, add the following two paragraphs:
> >
> >    Once a party has sent a KEXINIT message for key exchange or
> >    re-exchange, it MUST NOT send any messages other than key exchange
> >    method specific messages (message numbers 30 to 49); NEWKEYS; and
> >    DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message
> >    (Section 7.3).  Implementations MUST NOT accept messages other than
> >    these between receiving KEXINIT and NEWKEYS messages.
> 
> Uh, what's wrong with SSH_MSG_UNINPLEMENTED?

OK, now this is a whole new discussion, opening issues with the original
draft. Can we get consensus and/or raise a ticket for the app-data-
during-rekey issue so that it doesn't get lost yet again in this
discussion?

That said, I can't see a reason not to include UNIMPLEMENTED, given its
status alongside the others in section 11 as being able to be sent by
either party at any time.

> 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.
(I admit that this is partly due to the IESG's apparent paranoia about
over-extensibility; I don't want to see the drafts being held up again
on my account if there's some gremlin we haven't thought of.)

> For that matter, I'm not convinced that the not-yet-defined messages in the
> 1-19 range should be excluded either.  All of the defined messages in this
> range have meaning at the lowest layer, independent of key exchange state.

Are you really suggesting that SERVICE_REQUEST and SERVICE_ACCEPT should
be permitted during key exchange?

> Why do we think any future messages in this range won't have the same
> property?

If we're unhappy with SERVICE_REQUEST and _ACCEPT (as I think I am),
then future messages in this range may have the same undesirable
properties as them.