Bill Karwin <bill@...> wrote:

>Doug Chamberlin wrote:
>>
>> I have long been in the camp that says that encryption of
>> client-server communications belongs outside the sphere and
>> responsibility of the database server vendor.
>
>Me too. My reasons are:
>
>o The state of the art of encryption moves too quickly for
> InterBase to keep up.

The encryption state of the art actually moves very slowly. New ciphers and
protocols must go through a proper (long) review process before they can
safely be used in real systems. Just look at the NIST AES process.

>o Once InterBase claims to support encryption, the vendor accepts
> a level of liability for security that too high.

I haven't checked, but I'm sure that the Interbase license explicitly
disclaims any liability for losses incurred through the use of the software.
In fact, I'd be surprised if it even accepted that the software was fit for
a given purpose.

>o An InterBase-only encryption mechanism is useless.
> Any security package that an IT shop chooses must account for
> any type of traffic, which is typically email, file access,
> http, and perhaps telnet.

They all have different requirements. There are more security services than
confidentiality: Depending on the circumstances, you might also need
authentication, non-repudiation or integrity. They are provided by applying
cryptography in different ways. Just encrypting your links does nothing for
process level authentication.

>For example, this week, I was working with a web-hosting company who
>insists that we access their machines using a VPN mechanism, connecting
>using IPSec. Additionally, they insisted that if I telnet into the
>machine, that I use ssh, not plain telnet protocol. It seems kind of
>redundant to encrypt by session when I'm already using an encrypted IP
>stack, but that's what they wanted.

I don't know if they were doing it this way, but ssh allows for
cryptographic authentication of clients. This is quite separate to making
the contents of a session confidential through encryption, and is quite a
reasonable requirement.

I think before any real discussion takes place about "using encryption", the
purpose needs to be clear. Encryption is useful for more than just making
things confidential.

Jan Mikkelsen
janm@...