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

Alan DeKok <aland@deployingradius.com> Thu, 05 January 2023 15:18 UTC

Return-Path: <aland@deployingradius.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 D6122C14F745; Thu, 5 Jan 2023 07:18:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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
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 oJRlvy2ygwbZ; Thu, 5 Jan 2023 07:18:28 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B62C5C14CE4B; Thu, 5 Jan 2023 07:18:10 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id A2C921AB; Thu, 5 Jan 2023 15:18:01 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [saag] [Pearg] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CABcZeBPc0r275AiCL=qWTnzFT9PoQ9WMHz+GcmQZG8pgv2dmbw@mail.gmail.com>
Date: Thu, 05 Jan 2023 10:18:00 -0500
Cc: John Mattsson <john.mattsson@ericsson.com>, "ietf@ietf.org" <ietf@ietf.org>, "pearg@irtf.org" <pearg@irtf.org>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, saag <saag@ietf.org>, "hrpc@irtf.org" <hrpc@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EB76682-E75C-413B-906B-6C5C7404A91C@deployingradius.com>
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> <CABcZeBPc0r275AiCL=qWTnzFT9PoQ9WMHz+GcmQZG8pgv2dmbw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gAwmos_EPQkHLFBIJ5nxQstL2W8>
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: Thu, 05 Jan 2023 15:18:33 -0000

On Jan 5, 2023, at 8:58 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. Essentially none of these threats are the province of the IETF,
> which defines networking protocols. 

  The output of the IETF is networking protocols.  The input of the IETF is "good will" effort from individuals and corporations.  Corporations whose highest priority is to ship hardware which can run "Flappy Bird" at double the frame rate and resolution of the previous version.

  Witness the experience John and I had trying to update EAP for TLS 1.3.  While NIST published a document in 2019 [1] mandating all government suppliers support TLS 1.3 by 2024, actual "boots on the ground" effort has been lacking.  The afore-mentioned corporations shipping new hardware have been conspicuously absent in all relevant technical discussions.

  i.e. the security of literally billions of devices depended on John, and one highly opinionated Open Source person who isn't being paid to be here.

  We need to do better.

  The work in the IETF is often done by people who are senior enough to be allowed to be involved, or who are independent enough to care.  In many organizations, people with operational and/or implementation experience are often too junior to be allowed to participate.  This has been my experience in many WGs.

   I've been reading all of this discussion about protocols and legislation with a bit of amusement.  I see all that as necessary, but it is not sufficient.  My (and Johns) experience with EAP highlights this.  If we hadn't chosen to do the work, there's a good chance that it either wouldn't have been done, or would have been done too late to meet legislated time frames.

  The IESG and the IAB should take a serious look at which protocols need updating.  They should see which people are allowed to be involved in the IETF, and where in the company they sit.  They should find ways to get more participation from people who have operational and implementation experience.

  Until that happens, the input of the IETF is insufficient "good will" to secure core protocols.  The output of the IETF is window dressing.  The foundation of the Internet is built on sand.

  Alan DeKok.

[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf