Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

["Perry E. Metzger" <perry@piermont.com>]

On Tue, 28 Oct 2014 16:33:36 +0100 Florian Weimer <fw@deneb.enyo.de>
wrote:
> * Perry E. Metzger:
> 
> > The trick is to make sure it isn't used as an instrument to
> > prevent ordinary people from booting software of their choice,
> > but rather is used as an instrument to assure that when they boot
> > the software of their choice, they're actually getting that and
> > not malware.
> 
> None of the existing boot verification technologies provides this.

Agreed. That said, it is important not to throw the idea out entirely
-- don't dump the baby with the bathwater.

> It's also difficult to reconcile this with full user autonomy—if the
> user can load previously untrusted key material (and especially if
> this is an expected step during installation of a free operating
> system), the firmware can no longer warn about malicious keys and
> malicious software (because the user has replaced the trust root).

The user could, however, be in charge of what trusted roots they
accept/load into the firmware, or could hand-enter the hash of the
software they are willing to load. This does not appreciably reduce
security provided it has to be done with physical access to the
machine and is properly designed. (I'm unwilling to produce such a
design on the fly without thinking about it hard.)

My only point was that there are legitimate reasons to want to make
sure you're only loading the code you're expecting to load. Many of
the sorts of technologies being discussed are actually of use. Heck,
Debian signs all their packages at this point to assure
non-tampering -- there is clearly a legitimate use in using
signatures to make sure you're getting what you want. The only issue
is, as you note, that many such systems (see iOS for example) also
prevent you from getting things you might want, which is distinct
from using such systems to assure that you get only what you wanted.

-- 
Perry E. Metzger		perry@piermont.com