Re: Async rekey?

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

>>    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: [...]

> One useful feature of this is that it provides detection and
> intolerance of implementations that forget to rekey at all.

Good point.  As long as at least one end thinks to rekey, it'll happen.

>> 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 think you'd still need _some_ means of putting pressure on the
> other party to actually get round to handling the KEXINIT sooner or
> later, or detecting if it persistently doesn't.

True.  I had been implicitly thinking of that already, though I hadn't
put it that clearly even to myself.

My motivating use case is slow machines, where a rekey makes
interactive connections lock up for long enough for the human layer to
not only notice but get annoyed.

I was thinking of performing the rekey in parallel with data transfer,
with NEWKEYS happening as soon as rekey is done - but I was also
thinking of some kind of limit, probably agreed upon as part of
extension negotation, on how long (in seconds and/or bytes) data
transfer could continue between KEXINIT and NEWKEYS.

Ultimately, it would have to be a quality-of-implementation issue.  An
implementation that implements the extension and then ignores the
negotiated limits on data transfer during delayed rekey is something
that there's no technical way of preventing, except via lack of
interoperability with implementations that do it right - much like an
otherwise stock SSH implementation that doesn't rekey at all.

/~\ 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