Matthew N. Dodd wrote:
>
> On Tue, 26 May 1998, Tom Lane wrote:
> > I used Diffie-Hellman for that purpose years ago, and perhaps could
> > still dig up the code for it. But I thought discrete logarithm had been
> > broken since then, or at least shown to be far less intractable than
> > people thought. In any case, D-H is pretty slow --- are we prepared to
> > add seconds to the backend startup time in the name of security?
>
> I think everyone is thinking too hard on this issue.
>
> Transport security should be just that.
>
> Use SSL or Kerberos encryption if you wish thoe entire session to be (more
> or less) unsnoopable/unspoofable.
>
> Trying to hack things in will only result in an incomplete and/or ugly
> solution.
>
> The way I see it people have several choices:
>
> - Run with no network listeners and therefore no network clients to expose
> to snooping/spoofing attacks.
>
> - Require SSLed or Kerberized connections, incuring longer startup times
> but insuring a secure channel.
>
> - Use SKIP or some other IP level encryption system to provide a secure
> 'virtual lan' insuring a secure channel.
>
> - Isolate communication across secure, private networks insuring a secure
> channel.
>
> So long as we make people aware of the risks they are exposing themselves
> to, adding 'security features' in places better left to lower level
> protocols is unnecessary.
>
HMM, you do make a convincing argument. As one of my H.S. teachers
used to say, we are putting "Descartes before Horace". Probably
better to just have the postmaster generate and issue a random number
to the client.
It would be nice if this can be done in a forward/backward-compatible
way. I.E. old clients that don't know ablout cancelling should be
able to work with servers that can cancel, and newer clients that can
cancel should be able to disable this feature if talking with an older
server. A rolling database gathers no development community :)
Ocie