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

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Wed, Jul 21, 2004 at 11:32:20AM -0400, Jeffrey Hutzelman wrote:
> On Wednesday, July 21, 2004 12:26:06 +0100 Jacob Nevins 
> <jacobn+secsh%chiark.greenend.org.uk@localhost> wrote:
> 
> > 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.

Well I'd have to object to the above,  as I'd want to be able to send other
transport messages (1 - 49).  Moreover the original message from Bill actually
said "must suspend transport of user data while rekey negotiation is in progress"
not "non-rekey-related traffic should be suspended for the duration of the rekey".

As to the response to receiving any such transport message,  that can be discussed...

> >> Uh, what's wrong with SSH_MSG_UNINPLEMENTED?

I agree to the point about needing to be able to send the above during the rekey.

> >> 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?
> 
> No.  Those don't fall in the realm of not-yet-defined, and clearly should 
> be excluded.

Well I'd suggest one treat those as protocol errors,  and send a DISCONNECT in
response.  However if someone did a non blocking rekey implementation
(say a subsequent enhancement),  then we may well want to accept these during
a rekey.

I'd say it's a quality of implementation issue,  in the absense of any extension
for non blocking rekey,  I'd make receipt of the above send a DISCCONECT.

I don't know that it actually needs anything in the document.  I suppose we could
explicity say that behaviour upon receipt of those two during rekey is unspecified.

> Again, if we decide in the future that message 17 should be permitted 
> during rekey, a new implementation won't be able to discover if its peer 
> support message 17 unless implementations that don't know what that is are 
> expected to send SSH_MSG_UNIMPLEMENTED.
> 
> On the other hand, if we decide that message 17 should _not_ be permitted 
> during rekey, all we have to do is say that when we define message 17. 
> Then new implementations will not send message 17 during rekey, and will 
> not accept it if they see it then.  Old implementations will continue to 
> send SSH_MSG_UNIMPLEMENTED, but that shouldn't be a problem.

Agreed.

DF