Hi,
At 09:09 12/12/00 +0100, Reckhard, Tobias wrote:
>I don't either. Many things can go unencrypted in many environments. It
>depends entirely on the specific application and the circumstances.
>Encryption and authentication are valuable assets, though, and have many
>meaningful applications.
I would be a liar if I say that encryption is a bad thing. I however think that
encryption solves specific parts of the problem. in particular, access control
has been handled through encryption, not to hide data, but to carry a proof
of identity, which is the basic step in access control if network filtering
is not
enough. now, what I wanted to say is that there still must be a shared secret
or a public key. In both cases, there is a deployment key, and I agree that
the worst problems are not technical (PGP is an example of a good deployment),
but either commercial (most PKIs ask you to pay for a certificate!) or
political
(encryption is regulated).
>Of course. 'The public' includes the good as well as the bad. I fail to see
>the point.
I was trying to say that as a user who downloads software, there is nothing
I can about it: I either accept the risks and download from a "public"
server, or
refuse that and stay alone! yes, I agree that if all servers used ssl so that
we can authenticate'em, it'll be better. but even that is not enough.
anybody can
get a valid certificate. that doesn't make him a good guy. In other words,
unless
there are legal options in encryption, we will still run the risk or only
accept very
known servers. The problems with credit cards on "malicious" servers are an
example of the risk. Though they have acquired whatever certs you want,
there is
no way to sue them if your card is overuser...
>True, encryption will also rarely play a part when anonymous FTP access is
>concerned, because freely available resources are being dealt with and most
>people couldn't be incriminated by public knowledge of their access of these
>resources. However, it could very well be beneficial for them to know that
>they are downloading what they believe from where they believe--enter
>authentication. And while the use of certificates isn't widespread yet, I
>believe that will change over time, so in the future, quite a few sites may
>have keys for you to use and verify.
I agree on that.
> > clear text passwords are still the most widely used method not because
> > everybody around is a dumb developper,
> >
>No, but many don't have the time nor the background to think about security
>and be able to introduce it into their product. And username/password is the
>traditional method of authentication, it's been around for ages, literally,
>so it's perfectly natural for it to be the first to spring to mind.
that's right, but I still think it is a very good method, provided one does not
forgte when and why. in a trusted environment, clear passwords are so
simple that
they are good. probably not secure enough to provide a proof of identity, but
one might have enough means to fight bad guys (legally I mean).
For example, I really don't mind someone logs in as myself, read my mail,
or whatever, provided he is good enough to stay invisible. The day I know/find,
he will regret it:)
>But there are a number of different methods and most, if not all have been
>evaluated and are well understood. They need to be supported by the products
>and there need to be ways to interface to them, those are the problem, not
>the (fictious) inexistence of sound authentication methods. Note that there
>is an article on user authentication in the latest issue of Cryptogram, in
>which Bruce addresses the problem that you need to trust the computer and
>software of the user when she performs authentication--no real news there,
>but even what is obvious to some needs to be said once in a while.
yes, that's a funny thing. it's similar to "trusting trust" (or something
similar) by
Richie about a compiler that contains code to allow him to log in, and even
to add the backdoor if the compiler is rebuilt...
hopefully, I don't work in the military area....
> > even TLS doesn't specify which algos to use. SSL has been "forced"
> > by netscape, that's why it "works".
> >
>While I don't know the specifics of TLS, I believe it is a good idea not to
>put requirements on the suite of algorithms to use, as you're losing out on
>extensibility to future developments. And I believe the parties involved
>should be able to specify which algorithms and methods they are willing to
>support--that's the way it already is. If the client of a user of an
>organisation I'm involved in wants to do DES and no authentication to
>transport sensitive data, I instruct my server to dump the request.
again, I agree. That's the right way.
> > - how to share public keys. PKIs are still in their infancy, and co-trust
> > is still far from reality...
> >
>But the methods are there and they work, technically. The organisational and
>social problems are larger obstacles, though.
I think the economic problem is the hardest here. PKIs should provide "free"
service to make people get in, but have to find some way to get their money
back. and here, we need innovation...
> > - how to convince our states that encryption is not only good for
> > terrorists, ...
> >
>Yes, that's a problem.. Quite a substantial one in France, isn't it?
not as substantial as many think, though!
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
