To: "scott.marlowe" <scott.marlowe@ihs.com>
Cc: Curt Sampson <cjs@cynic.net>, pgsql-hackers@postgresql.org,
	pgsql-interfaces@postgresql.org
Subject: Re: Speed of SSL connections; cost of renegotiation 
In-reply-to: <Pine.LNX.4.33.0304110855430.2900-100000@css120.ihs.com> 
References: <Pine.LNX.4.33.0304110855430.2900-100000@css120.ihs.com>
Comments: In-reply-to "scott.marlowe" <scott.marlowe@ihs.com>
	message dated "Fri, 11 Apr 2003 09:07:11 -0600"
Date: Fri, 11 Apr 2003 11:24:33 -0400
Message-ID: <11759.1050074673@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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