Re: Transport messages during kex

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Everyone,

Is everyone OK with the following proposal?
- Integrate Jacob's replacement Section 7.1 from below.
- Integrate Jacob's text in other parts of the document as noted in
http://www.chiark.greenend.org.uk/~jacobn/2004/07/ssh2-kex-data-diff.html

If I don't hear objections, then I'll incorporate those changes into
[TRANS].

Thanks,
Chris

On Fri, 23 Jul 2004, Jacob Nevins wrote:

> 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.
>