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
- IETF Chair Salz, Rich
- Re: IETF Chair Brian E Carpenter
- Re: IETF Chair Sarah Banks
- Re: IETF Chair Carsten Bormann
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Salz, Rich
- Re: IETF Chair Timothy Mcsweeney
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Kyle Rose
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Kyle Rose
- Re: IETF Chair Timothy Mcsweeney
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Carsten Bormann
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Salz, Rich
- Re: IETF Chair Timothy Mcsweeney
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Salz, Rich
- RE: IETF Chair Khaled Omar
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Mezgani Ali
- RE: IETF Chair Khaled Omar
- Re: IETF Chair Phillip Hallam-Baker
- Re: IETF Chair Phillip Hallam-Baker
- Re: IETF Chair Theodore Y. Ts'o
- Re: IETF Chair Leif Johansson
- Data at rest (was Re: IETF Chair) Robert Sparks
- Connections, and timing (was: IETF chair) Keith Moore
- Re: IETF Chair Phillip Hallam-Baker
- Re: IETF Chair Barry Leiba
- Re: IETF Chair Phillip Hallam-Baker
- Re: blockchain, not IETF Chair John Levine
- Re: IETF Chair Michael Thomas
- Re: IETF Chair Phillip Hallam-Baker
- Re: IETF Chair Benjamin Kaduk
- Re: IETF Chair Stephen Farrell
- Blockchain is alchemy Phillip Hallam-Baker
- Re: Connections, and timing (was: IETF chair) Amelia Andersdotter
- Re: IETF Chair Ben Laurie
- Re: IETF Chair Larry Masinter
- Re: IETF Chair Timothy Mcsweeney
- Re: IETF Chair Timothy Mcsweeney
- Re: IETF Chair Timothy Mcsweeney