Re: [Pearg] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Brad Chen <bradchen@google.com> Fri, 06 January 2023 15:01 UTC

Return-Path: <bradchen@google.com>
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 283A8C137812 for <ietf@ietfa.amsl.com>; Fri, 6 Jan 2023 07:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.596
X-Spam-Level:
X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKr7KXPjtzkg for <ietf@ietfa.amsl.com>; Fri, 6 Jan 2023 07:01:19 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA184C1522C2 for <ietf@ietf.org>; Fri, 6 Jan 2023 07:01:15 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id bt23so2291282lfb.5 for <ietf@ietf.org>; Fri, 06 Jan 2023 07:01:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/24NkhKvCNL6FTWSZX1onhKmURDmV2EGOCt9rGWaeBc=; b=lXr+ZfzjHqMo6SQ5vBxF7nL1QPw7Sm814+fSAwDmTIoW9NWsCHzVe1XwI7VSbkJozd SU93zO2Klk1IKV7JpG87WbBxytkxorANvFXqFxQw9YlS14UW8Q/xfuPdkL9EzVYECHAc uEYmHuKXRlshOaLO2wDGPoOfm6J7vNNKcR0GF/csYUazEw4xvIzfk1dz9ezBneZfTMO5 eM9sV4dgA4gN9MHVD129NBSEoLi0jZsrAuW3WFWfmSL8IPVTrhzYsQG033UWulh7+QEr OKwSla49rOf7dxJRhSjvyDtWn8/MkOpJH+mPlThd8DYCURpJZl9PLG0QhP3gvDD1rKOC jPSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/24NkhKvCNL6FTWSZX1onhKmURDmV2EGOCt9rGWaeBc=; b=uJFyidTqpTsX42iueKm+eTfPYVv/qUOpxKDd8lhKD8rh3+jPtVDcb59ViUq4+EonNC xeCqoLwzxUq4CrVCNcAKZM+9wZjrzRTb8s+Nh2S+SR6d/IkiJRBIwwq7C/fc90w8aY31 UZfY78250d80LNktN4NgUk4j9E+8ytvmvEL43zAPgm8ETDHGM3wJAqbdiWphHv3apejz aBb3FpQp84ibeXGRSjex1aqie+XBA2MPBK7ihcDXwMMiI7Jnj5ZdMYYCLarB+fhM3AYR 71lcl1VT8yBzcZMQ3f3K2+c7uc098J4NDTUbiK1zUhA7DlUxsk2LDYadbnTZFdnewS/G +r0Q==
X-Gm-Message-State: AFqh2ko4TCg3nyLL93yl9jKzfCiQgjRg50PQhV8saIFK0R67KH7oSDka ifmzL53eqtQeO1LFMhTC5kOJ7VCAdOZYewwZinNzBw==
X-Google-Smtp-Source: AMrXdXsnSWr0UHZqF5/5kNiG/Osaofh4BhYxeVxHf+A/mw3AXCTTPpkklMVEoE6gSotdpt6bsiqfoYDOYT1QJ7yRym0=
X-Received: by 2002:ac2:4e81:0:b0:4cb:38e:776b with SMTP id o1-20020ac24e81000000b004cb038e776bmr1965175lfr.688.1673017272936; Fri, 06 Jan 2023 07:01:12 -0800 (PST)
MIME-Version: 1.0
References: <HE1PR0701MB305098F652DBC34E3C40810B89F49@HE1PR0701MB3050.eurprd07.prod.outlook.com> <764163366.39904.1672842828297@appsuite-gw2.open-xchange.com> <CABcZeBNA_nJ2waQVENUvEXro91wAYOcH0ZxWqbLH4hoKcGkosw@mail.gmail.com> <9658281.42904.1672912808774@appsuite-gw2.open-xchange.com> <CA+9kkMBLiijcAyLYn_6h8z3N00EDaxdP=f7P2-qUt4Bn1iSWEg@mail.gmail.com> <HE1PR0701MB30505DC24A725E014D60FE0189FA9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <560fae4b-8624-f4ff-63a9-78e4362a5939@netmagic.com> <CAFzihuVwNEhW0trz6UP-KC6YNOFp+puvUcDkroVJkPXjSe8drQ@mail.gmail.com> <9F859ABE-6AB0-4376-9395-ACA9431AE073@mnot.net>
In-Reply-To: <9F859ABE-6AB0-4376-9395-ACA9431AE073@mnot.net>
Reply-To: bradchen@google.com
From: Brad Chen <bradchen@google.com>
Date: Fri, 06 Jan 2023 07:00:47 -0800
Message-ID: <CAFzihuWW1V4g+fUsOu3+xE6V3E0ZW-BV+6nTnXHwwROCSDKiLA@mail.gmail.com>
Subject: Re: [Pearg] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
To: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>
Cc: bradchen=40google.com@dmarc.ietf.org, vittorio.bertola=40open-xchange.com@dmarc.ietf.org, "ietf@ietf.org" <ietf@ietf.org>, "hrpc@irtf.org" <hrpc@irtf.org>, "pearg@irtf.org" <pearg@irtf.org>, saag <saag@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000004ce43905f199b09b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/57CNL_00UXlZ8VmteVh1wiFDBmo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <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: Fri, 06 Jan 2023 15:01:22 -0000

Thank you for the thoughtful feedback. I will be first to admit I do not
know enough about the IETF and as I dig into this thread and recognize
various participants I am learning a few things. I completely agree that
engineers and the IETF have a substantial role participating in the policy
discussion. Engineers can invent solutions to open problems. More broadly
they need to provide an authoritative opinion on what is possible and what
is impossible regarding technology, and provide expertise on cost and other
implications of a technology option. When technology is the wrong way to
solve a problem, engineers need to be a part of the conversation to explain
why. It is necessary and proper that the IETF contribute to the broader
expertise required to recognize problems that are amenable to a technology
solution and those that are not.

At Google I work on public safety. I think in my comments above I may have
overreacted to some of the language in this thread. I apologize if that was
disruptive. However my reaction is also coming out of my broader
experience, and my frustration at times with technical designs that have
the consequence of sacrificing one human right for another, while ignoring
notions of responsibility and concretely making safety worse. The industry
has made magnificent progress on privacy in the last decade, driven by the
leadership, sometimes self-interested, of a subset of players. I can't say
the same thing about our progress on public safety; on the contrary I would
argue our progress has been negative, and our trajectory is yet to be
corrected.

Brad

On Thu, Jan 5, 2023 at 5:19 PM Mark Nottingham <mnot=
40mnot.net@dmarc.ietf.org> wrote:

> A few thoughts on parts of this thread --
>
> > On 6 Jan 2023, at 12:19 am, Brad Chen <bradchen=
> 40google.com@dmarc.ietf.org> wrote:
> >
> > I question whether the IETF has the competence to unilaterally determine
> policy in this space. Recent comments on this thread reassure me that some
> of us are at least equipped to recognize the limits of our competence and
> to recognize the discretion that the IETF needs to exercise in how we
> impact policy.
>
> and:
>
> > On 6 Jan 2023, at 3:20 am, Vittorio Bertola <vittorio.bertola=
> 40open-xchange.com@dmarc.ietf.org> wrote:
> >
> > Yes, I totally agree. Ten years ago, the IETF sincerely (with the best
> of intentions) and naively thought to be in charge of setting this tradeoff
> in Internet communications.
>
>
> I'm going to pick on the language used here, because the framing of the
> IETF as "unilaterally determining policy" or "being in charge" leads the
> reader to assume that we should defer to other, seemingly more
> authoritative institutions.
>
> In fact, policy for the Internet isn't set by any one entity -- it's
> polycentric / decentred governance, a trend in regulation that's been
> widely recognised now for a couple of decades. Even inside a single
> country, policy matters are often arrived at through collaboration between
> many stakeholders and often are effectively controlled by non-state actors.
> When global, this is transnational private regulation and there are many
> examples of it beyond the Internet. It means that we need to become
> comfortable in our role co-regulating the Internet, not try to claim
> control or cede it to others.
>
> The IETF has considerable legitimacy as not only an institution that can
> create useful technical documents, but also as a steward of the Internet
> architecture as a means to realise and maintain a global public good, even
> as we ourselves are an essentially private institution. In contrast, state
> actors are still relatively unproven in their roles as Internet regulators.
>
> Of course we should understand what other regulators of the Internet are
> doing and what their attitudes are, along with those of other stakeholders
> -- for our protocols to be successful, doing so is essential. That doesn't
> mean, however, that we should tie our hands or ask permission before
> developing protocols. Nor does it mean we should just give up and hand over
> change control to others, or jump to accommodate their actions when we
> identify serious concerns around security, privacy, ossification, or other
> areas where we have expertise.
>
> > The direction explored on this thread represents a tremendous and
> important task. I'm pretty sure the way to fail is for engineers to go it
> alone. To be competent, we need to figure out how to recognize the
> relevance of disciplines like law and philosophy and history, and how to
> benefit from their perspective on these issues.
>
> Very much agreed here, but recognise that the IETF isn't 'just engineers'
> -- we are an open organisation representing diverse viewpoints and
> experiences. Is it diverse enough? Of course not, but we can take steps to
> improve this and other factors that will shore up our legitimacy for the
> task at hand. I'd much rather do that than bury our heads in the sand --
> which is the outcome whether we defer to external parties *or* we ignore
> them.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> --
> Pearg mailing list
> Pearg@irtf.org
> https://www.irtf.org/mailman/listinfo/pearg
>