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