Re: [Secdispatch] draft-campling-ech-deployment-considerations (was: Request for a slot at the Secdispatch IETF 113) Session

Mark Nottingham <mnot@mnot.net> Fri, 07 October 2022 23:44 UTC

Return-Path: <mnot@mnot.net>
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 7FC00C1524C9 for <secdispatch@ietfa.amsl.com>; Fri, 7 Oct 2022 16:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=fDPgDL95; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dBplJCrj
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 YFU-Zfa-bY_v for <secdispatch@ietfa.amsl.com>; Fri, 7 Oct 2022 16:44:51 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 95B98C1524AB for <secdispatch@ietf.org>; Fri, 7 Oct 2022 16:44:51 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1CE8B5C0130; Fri, 7 Oct 2022 19:44:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 07 Oct 2022 19:44:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1665186290; x= 1665272690; bh=MAEyUeRIDFWyKlcnGqoxm4fit0jan9ugX3+cQtp1QCA=; b=f DPgDL95YcTQaSeoUqeXihliavpREFrRK7hcUN834HdEQ/uP6lnFyHvlCW8+zVEVo WSCPSZjkKW7kWSiIeQ70qTqJCWt2AReeuv4+AGLwxtU0m8qAikpz7v9Vwnw0i0JK UZNGBz7B/F4AIyCgNgDEJzR2usgc0lyQp9jcpdQwTJDgrnsw34EY8Q9icwwSgZqf G3YEV2RJvtaYfnAS1ieb7kOKHmGCqtC6HHeuS5k1H0mxK0HxVA8+tnD05HkGF+7u 7feXoPcZhreKzhOVW/lbQGdcHZCdlmW2BKb9A68OKAuOEE1A0jXAT89U8ufOjUyM 1ovS7MQId3gyGXJcN/4uQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1665186290; x= 1665272690; bh=MAEyUeRIDFWyKlcnGqoxm4fit0jan9ugX3+cQtp1QCA=; b=d BplJCrjyocx98w9G/WRKOnUM/4AeafP3lmJmE+5voHjjw9k2pP51DYyiKQO6SDfY KEi2qJOUCNVZNNJH1M7p2lSNAK2sBgW2RJNX1PmIWdRD6vNAeil7+uenatHJRYI9 0jd0N+RuMU+tezDQrOJGe+bYt6yqsum+TIlBom9vXCxT15ILpV8VUzyA5FCk/4oE OzsVOEdMa17KjTy0lzEPgfZknqzLH9scKJaSXlZowvxMFjasMpZvALkU4h/aCEqQ xc3sU/SV9bryg5J2RGcBfcynOpkJ2Ym+S9vNc0WDYRc61n3nEXanrhuKzDDDfZPz AJOCGaCAe//ReUnaTtTyQ==
X-ME-Sender: <xms:8blAYxjpsB6W0VcMsdbwraJGjvGSCQ3Hwk0mYsqtUhN0afohXbVqNQ> <xme:8blAY2Dr1Px5P08Op1-h3hsQLvIl_hAwjCkt_QRs495MTTGS7BaLFIYDPMbS5xndz b74RR9gw9VJ8tEkog>
X-ME-Received: <xmr:8blAYxHQACYSVP1mb0Io91tdXdUjKoReCxee8uwMOI8S0fwhiqJu5a9URb7YrCWdCQUAbDOne5q9kXRaknib78lfVShGYexTOkCKNpTlcwZocuZF1fW3gSi6>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeikedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnheptddtgefgueevtddugfdtkeffudegveetffegjeelhfdvtedvueejteegueeg teetnecuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:8blAY2RJ17tX02bA5XGjIYRFwcsYaM9Ak3pzSPmrdjFJHoNwNtbtPw> <xmx:8blAY-zbDQPsGzRLlHdmHTpQEAP3mHFCZHgIGHJWbTqxEKyQhCwaUw> <xmx:8blAY85H86Yo4RjElZpFQVmxfq7bq0rU-7LJJTSqFO62pxngPMiiaQ> <xmx:8rlAY5_6RxqBpom8yAyP8yMYmHNToNCwntYTTKxxLvZPeCxk0yqgqA>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 7 Oct 2022 19:44:47 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <Y0BwGS4u/smgf61u@faui48e.informatik.uni-erlangen.de>
Date: Sat, 08 Oct 2022 10:44:43 +1100
Cc: Andrew Campling <andrew.campling@419.consulting>, David Schinazi <dschinazi.ietf@gmail.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <45F08DA2-47D4-4CAD-9AC7-A1BD6B2FF079@mnot.net>
References: <Y0BwGS4u/smgf61u@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/R42nDqB6h38KEQfrsLCneM20ZAs>
Subject: Re: [Secdispatch] draft-campling-ech-deployment-considerations (was: Request for a slot at the Secdispatch IETF 113) Session
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 07 Oct 2022 23:44:56 -0000

On 8 Oct 2022, at 5:29 am, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> Aka: IMHO what we need is a way for connection setup to be performed in a way
> that a client-device trusted man-in-the-middle can validate the server
> certificate and client credentials for the trusted man-in-the-middle.
> But nothing else, especially not the payload. 

That might be an interesting path forward. It reminds me of similar discussions in HTTP -- it would be interesting if a trusted intermediary (e.g., a CDN) could perform limited functions like caching, without giving them full access to modify (and possibly read) content. 

The nature of the threat model and what 'trust' means in these circumstances both deserve a lot of discussion first, of course, but in general the trend we're seeing is a movement towards more fine-grained definitions of partial trust to perform specific tasks (e.g., PPM, OHAI, oblivious DOH).

Cheers,

--
Mark Nottingham   https://www.mnot.net/