Re: My take on the BoF session

["Mike Petkevich" <michael_petkevich@bmc.com>]

> So, I don't quite care what you call it as long as it's clear that the
> goal is to pragmatically improve security.

Usability always comes at the expense of security.  It is desirable to let
the user to decide how much security the installation agrees to pay for the
gain in usability. Such decision should be done by well informed user

The problem of CA storage is being addressed typically by individual
products, i.e. browsers are shipped with trusted CA roots hardcoded. The
unbroken seal on CD serves as out-of-band token you trust. Secondly, trusted
roots can be read at run time from a protected keyfile. Using DNS for CA
certs storage would be done as a tradeoff.

It appears that the debate is about security/usability tradeoff.  Security
deployment is a pinnacle of this: a key has to be created and signed.  The
helpful assumption, which can be made here, is that you have to trust your
network at a time of deployment. Otherwise do not install keys, if you think
you are vulnerable.

So it becomes a risk management problem.  As a system designer I do not want
to make such decisions for a  user.
Rather, I would like to give user a notice that  more usability will bring
more vulnerability and less security.

Regards
Mike.








----- Original Message -----
From: "Bill Sommerfeld" <sommerfeld@orchard.arlington.ma.us>
To: "Keith Moore" <moore@cs.utk.edu>
Cc: "Edward Lewis" <lewis@tislabs.com>; <keydist@cafax.se>
Sent: Monday, March 25, 2002 6:12 PM
Subject: Re: My take on the BoF session


> > > So, last I checked, the DNS root was *already* a critical service.
> > > Someone who can get bogus data into it can already cause no end of
> > > chaos.
> >
> > right, but placing an even greater trust it it does not seem wise.
>
> Ah, but in the case of ssh as deployed today, we aren't actually
> placing any greater trust in the DNS by putting application keys in
> the DNS, since ssh first-time-connects are already vulnerable to
> someone putting bogus data in the DNS!
>
> > I think it would more accurate to say that you are trying to increase
> > the difficulty of a MitM attack on ssh's initial key exchange (and
> > that of similar protocols), than that you are providing some level of
> > assurance.
>
> So, I don't quite care what you call it as long as it's clear that the
> goal is to pragmatically improve security.
>
> - Bill