From: | Michael Ledford <mledford(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recent vendor SSL renegotiation patches break PostgreSQL |
Date: | 2010-02-03 16:52:08 |
Message-ID: | 8adf46ea1002030852w1250e47bu18055e49b2778a10@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Renegotiation after X amount of data is the recommended method AFAIK,
> because it limits the volume of data available to cryptanalysis.
> What makes you think that elapsed time is relevant at all?
>
> regards, tom lane
You are correct. In that volume of data also matters. It depends on
what kind of attack you are trying to minimize here. In my particular
use case I fluctuate between idle and busy but mostly low bandwidth.
You have four different primary cases that you are possible:
1) timed method on an idle link (or low usage)
2) timed method on a busy link (or high usage)
3) data limit on an idle link (or low usage)
4) data limit on a busy link (or high usage)
The timed method is more optimal for case 1.
The data limit is more optimal for case 4.
Case 2 gives an attacker more data to do crypto-analysis.
Case 3 gives an attacker more time to work with the current secret key
on a live link.
Depending on your use case, being able to work with a live link is
worse than working with the data postmortem. There is I'm sure some
hybrid in the middle between these where optimal lives.
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-03 16:58:36 | Re: Recent vendor SSL renegotiation patches break PostgreSQL |
Previous Message | Tom Lane | 2010-02-03 16:50:43 | Re: Hot Standby and VACUUM FULL |