Re: IETF Chair

"Theodore Y. Ts'o" <tytso@mit.edu> Wed, 14 October 2020 14:20 UTC

Return-Path: <tytso@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A7A3A0DFE for <ietf@ietfa.amsl.com>; Wed, 14 Oct 2020 07:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uMxsNUw1bCP for <ietf@ietfa.amsl.com>; Wed, 14 Oct 2020 07:20:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC53A0DEF for <ietf@ietf.org>; Wed, 14 Oct 2020 07:20:01 -0700 (PDT)
Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09EEJtIM018788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 10:19:55 -0400
Received: by callcc.thunk.org (Postfix, from userid 15806) id E036F420107; Wed, 14 Oct 2020 10:19:54 -0400 (EDT)
Date: Wed, 14 Oct 2020 10:19:54 -0400
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Timothy Mcsweeney <tim@dropnumber.com>, "ietf@ietf.org" <ietf@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Subject: Re: IETF Chair
Message-ID: <20201014141954.GB18373@mit.edu>
References: <2B51679C-2BED-4F7B-B146-FF1524B00AA5@akamai.com> <C775E80B-9A31-492E-BA6A-96F9FE831316@akamai.com> <128277543.164613.1602611739735@email.ionos.com> <CAMm+LwjCGVUuFXK+fAzpV176hseXB9iLzC-7OZQZf=ca9+3x0A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwjCGVUuFXK+fAzpV176hseXB9iLzC-7OZQZf=ca9+3x0A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XCBHmPu7ggAzvjeyD_n8mGOtm_o>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 14:20:02 -0000

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.).

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

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

					- Ted