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