Re: IETF Chair

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Oct 14, 2020 at 10:20 AM Theodore Y. Ts'o <[e-mail]> wrote:

> On Tue, Oct 13, 2020 at 07:22:10PM -0400, Phillip Hallam-Baker wrote:
> > The biggest security problem we face today is breach of data at rest, a
> > confidentiality problem. But 90% of the efforts of the academy and 99% of
> > those of commerce are focused on the Blockchain, an integrity technology.
> > Meanwhile it has taken me most of the last five years working in various
> > forums to persuade people to look at threshold decryption, a technology
> > developed in the 1990s that is actually a confidentiality control capable
> > of securing data at rest.
>
> I'd agree, but at the same time, I'll note that securing data at rest
> is generally not an issue which is solved via internet protocols and
> interoperability guarantees, but rather is something that needs to be
> designed in hardware (e.g., trusted key stores, firmware verification)
> and in software (trusted boot, multiple layers of encryption in the
> software stack, bring your own key for those customers who demand it)
> and in operational practices (reduction of people with privileged
> access, two person controls, auditing, etc.).
>

That is how we have been trying to do it for 20 years. And the result was
the Snowden breach. If the NSA can't run that stack and make it work, it is
hardly surprising if nobody else can either.

All the things you describe are useful as part of a solution. But they
don't get to the heart of the matter which in my view is separation of
duties. You cannot expect security if you place absolute trust in any one
individual or service. There will always be an insider threat. Which is why
we need to divide the private keys. Once you start to look at applying
threshold on a large scale, it is clear that you need a threshold key
infrastructure to manage the issue and use of the key shares. And once you
start to look at managing the shares it becomes clear that you need to make
use of threshold techniques to do that.

An example of the sorts of things which are needed to secure data at
> rest can be found here[1], from my employer, but all cloud providers
> should have something similar (or they'd better, if they want to
> retain customer trust).
>
> [1] https://cloud.google.com/security/overview/whitepaper


Right now, Google has how many billion passwords stored in its cloud
services?

One day, one of the lawyers will look at that and realize that you have
collected what one of my Microsoft friends used to describe as a steaming
pile of liability.

There are many commercial offerings out there but few that have even
explained their security controls and none that I am aware of that have
been subject to full public review. And it is hardly surprising that
password vaults have been one of the chief targets of hackers.

The problem with the password vault providers is that their mission is to
provide a proprietary solution that makes using passwords easy. What the
Internet desperately needs is a solution that provides a transition path
out of using passwords altogether.

Every device that is configured to use my password vault has end to end
security - the service provider does not have any form of access (that is
not a unique claim, but I have yet to see anyone else provide proof of that
claim). But the mechanisms I use to provision decryption key shares to
devices allowing them to access the password vault also provisions public
keys for authentication. So those devices can also authenticate using FIDO
(or equivalent). No smartcards needed.

If you look at this, you'll find that most of it is out of scope for
> the IETF.
>

PKIX was IETF work and one of the few security area protocols that actually
succeeded. If PKI is in scope for IETF then TKI needs to be.

The audience I need to convince to make this work is not the audience here.
It is the board rooms. I used to sell seven figure PKIs to C-suite members.
In the 20 years I worked for other people, I made very sure that I kept on
top of every new technology that might affect our business so that when I
got a call from the CEO, I could tell them exactly what it was about.

Perhaps some folk here might want to start considering the power of
threshold encryption and what it means for cloud security now just in case
they get asked rather than reassuring themselves that the current approach
is working.