Hi again, mouss, folks.
> At 10:39 11/12/00 -0800, Martin wrote:
>
> >Oh, is that what you think? Everything SHOULD be encrypted, there's no
> >excuse (in this day and age) for the existence of non-encrypted traffic
> of
> >any sort, even if you're only employing weak encryption.
>
> I don't wanna get into flames, but I don't agree on this.
>
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.
> while encryption
> soles the problem of accessing his own host where one has an account
> and a shared key, it is not easy to allow public guys to access a
> public host without allowing bad guys to come the same place.
>
Of course. 'The public' includes the good as well as the bad. I fail to see
the point.
> also, when considering outgoing ftp to public hosts, there is no point
> in encrypting anything, not becuse I don't want, but because the site
> has no key to share with me:)
>
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.
> 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.
> but because
>
> - there is no standard to tell how to do a secure authentication.
>
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.
> 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.
> - 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.
> - 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?
Cheers,
Tobias
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
