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

From: der Mouse <[email-masked]>
Date: Tue, 3 May 2005 05:14:15 -0400 (EDT)

I was just working on implementing draft-harris-ssh-rsa-kex-01, and I
ran into a question.

Everything is clear for the first kex.  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?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ben Harris <[email-masked]>
Date: Tue, 03 May 2005 12:00:53 +0100

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

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.

-- 
Ben Harris

---

From: der Mouse <[email-masked]>
Date: Tue, 3 May 2005 23:41:59 -0400 (EDT)

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