Re: [arch-d] Time to reboot RFC1984 and RFC2804?

John C Klensin <john-ietf@jck.com> Mon, 12 October 2020 19:27 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA023A0400 for <architecture-discuss@ietfa.amsl.com>; Mon, 12 Oct 2020 12:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Nm9JqguOaOk1 for <architecture-discuss@ietfa.amsl.com>; Mon, 12 Oct 2020 12:27:33 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA003A03FB for <architecture-discuss@ietf.org>; Mon, 12 Oct 2020 12:27:33 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kS3Tm-0007ZK-Dm; Mon, 12 Oct 2020 15:27:30 -0400
Date: Mon, 12 Oct 2020 15:27:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: Christian Huitema <huitema@huitema.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: architecture-discuss@ietf.org
Message-ID: <47EA7F173A4205E1D1DC87A7@PSB>
In-Reply-To: <5021a377-e9ca-1580-c2f0-3351b9f5fe04@huitema.net>
References: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com> <975E28FE326C22E8CD32DCC8@PSB> <5021a377-e9ca-1580-c2f0-3351b9f5fe04@huitema.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/4LXWEV_L0iCyDM-hMYCHXqDiaJY>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 19:27:35 -0000


--On Sunday, October 11, 2020 15:50 -0700 Christian Huitema
<huitema@huitema.net> wrote:

> On 10/11/2020 2:20 PM, John C Klensin wrote:
> 
>> It seems to me that we (very broadly defined) may be headed
>> into a period in which:
>> 
>> (1) We are forced into a choice between encryption and other
>> technical privacy protections against attacks (borrowing the
>> 7258 language) by individuals and attacks by governments
>> (including law enforcement), especially governments who have
>> jurisdiction over the sender, receiver, or other.  The default
>> if we don't choose and make the distinction clear to others
>> may be "neither".
>...

> There may be something else. The government actions typically
> operate through application providers acting as gatekeepers,
> as in "Facebook, please provide me a clear-text version of
> these messages". If there are just a few platforms managing a
> large share of the communications, governments merely have to
> lean onto these platforms to obtain what they want. And if a
> company is running a big communication business, it will come
> to terms with local governments in order to protect that
> business. If the IETF wants to protect individual freedoms,
> then it might want to focus on distributed architecture for
> communication services.

Indeed.  While I see that as a special case of "who are we
trying to protect against", it is quite different in some ways
and worth calling out separately.   But it also means we should
be thinking very carefully about technologies that, rather than
keeping some information private, merely shifts around who has
access to it to a different (and smaller) set of large providers
who might have trouble resisting strong and focused government
pressures such as those you identify.   DoT and DoH come to mind
as things we should probably look again at from the perspective
of whether they increase the kind of concentration (and
associated risks) that you warn against.  So do anti-spam
technologies such as DMARC and, although it is much further from
the IETF's responsibilities, strategies to protect personal
information in DNS registry databases by effectively insuring
that large registry operators are the only ones with general
access to those data.

FWIW, I have noticed that there is one big difference between my
running my own servers for mail, storage, etc., and passing
those off to a large cloud or virtual service providers.  If
some governmental entity comes to that provider with sufficient
legal documents or threats (of the sort you mention or of the
use of force) and says "give me his files and records and don't
tell him we asked", they presumably get them and I presumably
don't find out.   If they come to me with the same request
(putting aside whether I would be able to destroy everything and
would have the nerve to do that), they presumably get the files
but there is zero chance of keeping me from finding out about
the request.  Sometimes that is important, sometimes not, but,
where it is important, distributed architectures and protocols
and operational arrangements that encourage highly distributed
services are prerequisite.

thanks,
   john