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

Tony Rutkowski <trutkowski.netmagic@gmail.com> Fri, 06 January 2023 20:59 UTC

Return-Path: <trutkowski.netmagic@gmail.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A7C1522AC; Fri, 6 Jan 2023 12:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Asjq6oMp4Mtl; Fri, 6 Jan 2023 12:59:18 -0800 (PST)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 5E92CC1522AB; Fri, 6 Jan 2023 12:59:18 -0800 (PST)
Received: by mail-qv1-xf2a.google.com with SMTP id t13so1770603qvp.9; Fri, 06 Jan 2023 12:59:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:references:cc:to:content-language:subject:reply-to :user-agent:mime-version:date:message-id:from:from:to:cc:subject :date:message-id:reply-to; bh=6uToY19c8jHcmCr0lMaB1apiztJSfAgZz7jo2sHBHE0=; b=qJRrLLLhgMYTichyMdcSre03IaTCnq03jnayVoNbM6DA/B9UKnx37aGyQWl9WPxHOr IToPwWZpgwt+5YU3nkgnhsax40FWGhEd06Vupl6Jx8Z//JkwelQGTVwqCgKFFSQf++Vc 0CUYQekze11x80A5wfGV95ZzXQQvgqQ4w72QNqQJOGGp6vod7cuMQ0qSevsDDDeUb80o qomf4axGnUlU/TDlfgHBH8QJrCf6P8LBsIpKauJgOgPMgLNIOou/0boYKwctkWvPZLJF BjxPljh8FwPMOpQsvWLXKXP2k1a4Z+nBw3l0mlp9/RPSvDsCSTmHeyVI92/aIusfIfcY nT0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:cc:to:content-language:subject:reply-to :user-agent:mime-version:date:message-id:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6uToY19c8jHcmCr0lMaB1apiztJSfAgZz7jo2sHBHE0=; b=GVZij3rj3P4ypBxb73wPwYvbzlsGulnKC3B6gMkOLJVaq9FGUUL3Kx9Jvw5sL15ItJ yUW8MxzO5mMA6LoJ5o6DWQFIrPHgoG7JIF13DM7xa2s+a+BQsWlgxPC0N4CKKMbNe8nL rm5EXLYGB9YKj+SxzLBs0cXjpzQ8OazFryuzI8adzU3qXbmn0CDmv/hKEcLHf84SJwHw OarHuXNYEsHQN0wRIiLOygom+22ZZ2/l5OGHuQcWaohteFz7DTAjgNscrSu9t2en64Lw qSbttbIjjTnkJip2j66ug6yxeGMDHkZkmS6DmAZP4ysHb1zpatjylCZAtdUP/wPp3W75 PehQ==
X-Gm-Message-State: AFqh2koYTSJMm/86PfvMkzn0q6LFfakSfYwbNJ2yMNDOAoQVZEPCsR/m E1Z+hLUuGMn715ckroulU+c=
X-Google-Smtp-Source: AMrXdXs7QwHCB4aKd1bq0iCq8V1SoEBNGU0jvAnreNuF6fYxL4pHLm3dZgg+7YRbWpOccFevWL346w==
X-Received: by 2002:a05:6214:400f:b0:4dd:c2c9:6d61 with SMTP id kd15-20020a056214400f00b004ddc2c96d61mr91236668qvb.5.1673038757331; Fri, 06 Jan 2023 12:59:17 -0800 (PST)
Received: from [192.168.1.249] (pool-70-106-222-156.clppva.fios.verizon.net. [70.106.222.156]) by smtp.gmail.com with ESMTPSA id bi1-20020a05620a318100b006fb0e638f12sm1099720qkb.4.2023.01.06.12.59.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Jan 2023 12:59:16 -0800 (PST)
From: Tony Rutkowski <trutkowski.netmagic@gmail.com>
X-Google-Original-From: Tony Rutkowski <trutkowski@netmagic.com>
Content-Type: multipart/alternative; boundary="------------Hr0OVSv0fplbOZAuA3wAlCcY"
Message-ID: <d974da5c-d08a-4a18-bfb3-1c665da6e6c7@netmagic.com>
Date: Fri, 06 Jan 2023 15:59:16 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Reply-To: trutkowski@netmagic.com
Content-Language: en-US
To: Adrian Gropper <agropper@healthurl.com>, bradchen@google.com
Cc: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>, 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>
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> <CAFzihuWW1V4g+fUsOu3+xE6V3E0ZW-BV+6nTnXHwwROCSDKiLA@mail.gmail.com> <CANYRo8jbq8nd1hRR3xgQGH6DBR+bmvSNP9p_n9CsMREvd3Nqvg@mail.gmail.com>
In-Reply-To: <CANYRo8jbq8nd1hRR3xgQGH6DBR+bmvSNP9p_n9CsMREvd3Nqvg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/EZezlGKK1NNqE8hRVAx5BZiCS6w>
Subject: Re: [Pearg] [saag] [hrpc] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 20:59:23 -0000

It is a pity the IRTF/IETF never seemed interested in enumerating, 
implementing, and measuring the entire array of human rights that are 
relevant for electronic communications.  See Human Rights as a Service 
(HRaaS), https://datatracker.ietf.org/doc/draft-rutkowski-hrpc-hraas/00/

The IRTF/IETF seemed to always focus highly selectively on a couple of 
rights, ignoring the others.  Clearly, the European Union and Council of 
Europe have done several orders of magnitude more to advance the broad 
array of human rights for internet services than what has occurred 
anywhere else.

--amr (opining as Sean McBride's former advisor and contributory on 
internet technology to his International Commission for the Study of 
Communication Problems.  Sean knew something about human rights.)


On 1/6/2023 1:50 PM, Adrian Gropper wrote:
> I want to thank Brad for looking beyond the technology and to point 
> out that safety and human rights _must not_ be framed as a dichotomy.
>
> The human rights perspective is, IMHO, about inalienable rights 
> whereas safety is almost always a matter of cost and compromise. When 
> a human rights consideration raises safety issues in the context of a 
> specific protocol, it's the role of the HRPC section of that protocol 
> specification to clearly identify the safety concern and suggest 
> mitigations for that safety concern. The mitigations might be costly 
> or might force changes to the protocol late in the RFC process but 
> because human rights are unalienable, there's no choice but for that 
> protocol workgroup to do the work.
>
> Simply put, ten years after Snowden, it's up to us to help all IETF 
> add an HRPC section along the privacy and security sections to _every_ 
> specification. If there's no HRPC, a protocol can simply just state that.
>
> Adrian
>
> On Fri, Jan 6, 2023 at 10:02 AM Brad Chen 
> <bradchen=40google.com@dmarc.ietf.org> wrote:
>
>     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
>
>     _______________________________________________
>     hrpc mailing list
>     hrpc@irtf.org
>     https://www.irtf.org/mailman/listinfo/hrpc
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag