Re: Speed of SSL connections; cost of renegotiation

On Fri, 11 Apr 2003, Curt Sampson wrote:

> On Thu, 10 Apr 2003, Tom Lane wrote:
>
> > So, questions for the group: where did the decision to renegotiate every
> > 64K come from? Do we need it at all? Do we need it at such a short
> > interval? And if we do need it, shouldn't the logic be symmetric, so
> > that renegotiations are forced during large input transfers as well as
> > large output transfers?
>
> Yes, you do want renegotiations, for two reasons. One is that if you use
> the same key over a long period of time, you offer too much same-keyed
> cryptographic material to an attacker, and increase his chances of a
> successful attack. The second is that you limit the amount of data that
> can be compromised should someone get hold of your current key. (Though if
> they've got that from your server, they've probably got access to the database
> itself, too, so I wouldn't worry so much about this.)
>
> I don't actually know how often you should renegotiate, but I'd guess
> that 64K is really very much not the right value. It's probably not
> enough for DES, and is way too much for anything else. One hour seems to
> be a popular session key renegotiation interval for SSH and IPSec; why
> not start with that?

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. Basing it on time introduces too much variability. You'd have
to basically say that x bytes is as much as you should encrypt with one
key, then base time t on t=xr where r is the max rate you can expect on a
given server, and rate can vary too wildly. In fact, setting a time
period of 5 minutes for large server might well be too seldom, and 30
minutes on the small slow Sparc IPC in the back room is too often.

If it is a GUC then the user can adjust it. I'm comfortable with that,
since there's a lot of variability to where postgresql gets used and what
it gets used for.