Re: draft-harris-ssh-rsa-kex-01

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> But what about re-keying?  Is the server reusing the same K_T as for
>> a previous kex a MUST, SHOULD, MAY, SHOULD NOT, or MUST NOT?
> My intention was that different key exchanges (whether in the same or
> different sessions) SHOULD use different RSA keys, largely so as to
> limit that number of session keys that an attacker gains access to by
> cracking a single RSA key.  I seem to have forgotten to actually
> write that down anywhere, though.  I'll fix that in -02.

That would be good.  Since it appears to be designed as an adaptation
of historical ssh1 practice to the ssh2 world, I would have assumed
there was an expectation that different sessions share the same K_T
when they occurred within reasonable temporal proximity to one another
(since something very much like that is what ssh1 did).

> This does make rekeying a bit of a pain for a single-threaded (or
> rather, single-thread-per-session) server, but that's why it's a
> SHOULD.

It's also a pain for any server running on hardware slow enough that
generating a key is an expensive operation.

I suspect what I'll do is simply use the most current available key at
any time (blocking if no key has been generated yet) and kick off a new
key generation in the background whenever a key is used.  Arranging to
background key generation should be interesting, but, I believe,
thoroughly solvable....

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