[Secdispatch] about draft-campling-ech-deployment-considerations (Re: Request for a slot at the Secdispatch IETF 113 Session)
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 22 March 2022 10:18 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A88C3A0DDE for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 03:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 DBycFxi3fxqD for <secdispatch@ietfa.amsl.com>; Tue, 22 Mar 2022 03:18:50 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5853A0E50 for <secdispatch@ietf.org>; Tue, 22 Mar 2022 03:17:44 -0700 (PDT)
Received: from dooku.sandelman.ca (dhcp-885d.meeting.ietf.org [31.133.136.93]) by relay.sandelman.ca (Postfix) with ESMTPS id 613BB1F458; Tue, 22 Mar 2022 10:17:41 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 83EB21A01C2; Tue, 22 Mar 2022 06:17:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mark Nottingham <mnot@mnot.net>, Andrew Campling <andrew.campling@419.consulting>, David Schinazi <dschinazi.ietf@gmail.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>
In-reply-to: <29ED5EBE-D5B5-435A-B32D-10BE19513A25@mnot.net>
References: <LO3P265MB209260DA72D1A8383FD64BBAC2119@LO3P265MB2092.GBRP265.PROD.OUTLOOK.COM> <CAPDSy+5X_SmRi026tLHrQU3Zc+oUPPOqwSJ+9HoGuMSd4wvQ=Q@mail.gmail.com> <LO3P265MB20920BC976D371AFDD3FFA1FC2129@LO3P265MB2092.GBRP265.PROD.OUTLOOK.COM> <29ED5EBE-D5B5-435A-B32D-10BE19513A25@mnot.net>
Comments: In-reply-to Mark Nottingham <mnot@mnot.net> message dated "Tue, 22 Mar 2022 13:17:11 +1100."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 22 Mar 2022 11:17:40 +0100
Message-ID: <745349.1647944260@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/OnrOCSh10qpUmpuqoLsUFZEesOg>
Subject: [Secdispatch] about draft-campling-ech-deployment-considerations (Re: Request for a slot at the Secdispatch IETF 113 Session)
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 10:18:56 -0000
{I wish the subject had been changed} I found Mark's explanation very very well worded, and so I clipped parts of it out (and top-quoted) below. I think that The Enterprise problem with TLS1.3 falls into this situation. They have, up to now, imposed terminating TLS proxies on their employees, without clearly informing them. The problem that they have is the rise of BYOD (and work from home, using my equipment, not theirs), and again the problem is imposition of an unauthenticated intermediary without permission. The argument against asking permission is that it is confusing for users. While that is partly a UI issue, it's also because many things are occuring which are not explicit. The whole HTTP-Authentication vs HTML-form-POST-authentication debate that we've come back to many times is an example of that. We haven't improved authentication in HTTP in a useful way, so we continue to have authentication occuring at the wrong layer. Mark Nottingham <mnot@mnot.net> wrote: > The underlying problem is that such "transparent proxy" services are > unauthenticated -- they rely on the user understanding that the network > is going to perform these services, and accepting their > imposition. They're also disproportionate, giving complete access to > all data flows and capabilities on the connection. ... > Performing these tasks in this fashion allows not only legitimate > authorities to impose them, but also illegitimate attackers. As such, > they're inappropriate for deployment on the Internet, and that's why > we're seeing efforts like ECH -- use of this data and the associated > control channel without explicit user authorisation is not > "permissionless innovation" (as your draft states), it's an open door > to abuse. Put bluntly, you (as a network operator) don't have a right > to "innovate" with my data (as a user) -- especially without my > permission. ... > It also doesn't mean that the path forward will be easy. What's > required is a discussion and implementation of interfaces for > offloading these functions from operating systems, applications, and > IoT devices -- potentially to somewhere else on the network -- in a way > that maintains users' autonomy, privacy, and security, and in a > proportional way (i.e., only as much access to data as required to > fulfil the task). That is difficult not only because of the inherent > user interface subtleties and potential for abuse/hijacking, but also > because there is little current coordination or convergence at that > layer. > The IETF has a very clear responsibility to assure that the protocols > it ships are secure -- hence, ECH. It *could* have a role to play in > responsibly offloading these functions, especially where the work > intersects protocol design. There is also other work to be done that's > squarely outside our scope. I'd suggest that you and your co-authors > focus on assisting those positive, forward-looking efforts rather than > trying to stop ECH deployment. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Secdispatch] Request for a slot at the Secdispat… Andrew Campling
- Re: [Secdispatch] Request for a slot at the Secdi… Kathleen Moriarty
- Re: [Secdispatch] Request for a slot at the Secdi… David Schinazi
- Re: [Secdispatch] Request for a slot at the Secdi… Andrew Campling
- Re: [Secdispatch] Request for a slot at the Secdi… Mark Nottingham
- Re: [Secdispatch] Request for a slot at the Secdi… Kathleen Moriarty
- Re: [Secdispatch] Request for a slot at the Secdi… Salz, Rich
- Re: [Secdispatch] Request for a slot at the Secdi… Eric Rescorla
- [Secdispatch] dispatching draft-campling-ech-depl… Stephen Farrell
- [Secdispatch] about draft-campling-ech-deployment… Michael Richardson