Thread: Re: [HACKERS] Speed of SSL connections; cost of renegotiation

"scott.marlowe" <scott.marlowe@ihs.com> writes:
> Ummm.  I'm not comfortable with using a time based period for 
> renogatiation.  What can move in an hour from a P100 on Arcnet versus a 32 
> CPU altix on switched fabric are two entirely different things.  If there 
> is a "sweet spot" for how often to renogotiate it would be based on 
> amount.

That's what I would think, too.  So we already have the right mechanism,
it's just a question of what the setting ought to be.

I realized this morning that there's probably a security tradeoff
involved: renegotiating the session key limits the amount of session
data encrypted with any one key, which is good; but each renegotiation
requires another use of the server key, increasing the odds that an
eavesdropper could break *that* (which'd let him into all sessions not
just the one).

So a too-short renegotiation interval is not only expensive time-wise,
but could actually be a net loss for security.

I'm beginning to think we need to consult some experts to find out what
the right tradeoff is.
        regards, tom lane

PS: the sshd setting that was quoted refers to how often a new server
key is chosen, which is really independent of choosing new session keys.
Does our SSL code even have the facility to choose new server keys?
If not, perhaps someone had better add it.

> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > Ummm.  I'm not comfortable with using a time based period for
> > renogatiation.  What can move in an hour from a P100 on Arcnet versus a 32
> > CPU altix on switched fabric are two entirely different things.  If there
> > is a "sweet spot" for how often to renogotiate it would be based on
> > amount.

Well, I suspect that the amount is high enough that you might leave a
connection from, say, a web server using the same key for days on end
if you set a reasonably high amount. Probably the ideal is to have a
maximum time and amount. But as you point out, if it's a GUC variable, it
can be set by the user.

Personally, I would tend to go for a time limit over a size limit
because a size limit leaves an open-ended time, whereas a time limit
puts a definite limit on size as well. (And a very powerful system going
full bore for a long period of time over a high-speed connection is
pretty rare.)

On Fri, 11 Apr 2003, Tom Lane wrote:

> I realized this morning that there's probably a security tradeoff
> involved: renegotiating the session key limits the amount of session
> data encrypted with any one key, which is good; but each renegotiation
> requires another use of the server key, increasing the odds that an
> eavesdropper could break *that* (which'd let him into all sessions not
> just the one).

This seems extremely low-risk to me; there's very little data
transferred using the server key.

> I'm beginning to think we need to consult some experts to find out what
> the right tradeoff is.

If you really want to know, yes. I would think there would be a paper or
something out there, but I failed to dig one up.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC