Async rekey?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I've noticed that my ssh connections, even those entirely internal to
my house LAN, will occasionally lock up for a little while.  I suspect
this is rekeying happening - when it happens, at least one of the
machines involved is always a fairly slow one.

I looked through the specs, and in 4253, starting about 2/3 of the way
through page 19, I found text saying that

   Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
   re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
   7.3), it MUST NOT send any messages other than:

   o  Transport layer generic messages (1 to 19) (but
      SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be
      sent);

   o  Algorithm negotiation messages (20 to 29) (but further
      SSH_MSG_KEXINIT messages MUST NOT be sent);

   o  Specific key exchange method messages (30 to 49).

I don't recall why this was done (nor indeed whether it was even
discussed).  It makes sense for initial kex, but it doesn't strike me
as conceptually necessary for rekeying.

Would there be any interest in relaxing this, so that data exchange can
continue in parallel with rekey computation?  Or has someone already
done that?  (I don't recall hearing of any, but that means little.)

I'm likely going to be doing it for my own use; I'm asking in case it's
already been done or in case there's any wider interest in something of
the sort - if it hasn't been done, I'd like to collaborate on at least
the design.  (I was thinking of a design based on negotiating some kind
of async-rekey extension....)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B