Re: [Secdispatch] Oblivious HTTP charter draft

Martin Thomson <mt@lowentropy.net> Thu, 18 March 2021 23:14 UTC

Return-Path: <mt@lowentropy.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 232E93A0DAE for <secdispatch@ietfa.amsl.com>; Thu, 18 Mar 2021 16:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.12
X-Spam-Level:
X-Spam-Status: No, score=-7.12 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=FbhoAp+7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VG24CgFd
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 giDnbVJzVQCt for <secdispatch@ietfa.amsl.com>; Thu, 18 Mar 2021 16:14:35 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914243A0DAD for <secdispatch@ietf.org>; Thu, 18 Mar 2021 16:14:35 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DF9335C01BE; Thu, 18 Mar 2021 19:14:34 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 18 Mar 2021 19:14:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=K0Erwbc25o6C5Aa71YPZgPA5xZmr fFvMUqQUgBq/dSY=; b=FbhoAp+7ldYjZaggIJxpFhn+W7Lca/xA3RqX+RaMEk1B gUuaGzRrLy/5x/Og7fC2sXDtuthE2DH4U/YmBv6MWMkqGFCoPx2PoxelkkbwF0zq XWrRdZ43VX1ooMELYJ9jBt/ONBot22k4M56WfjFta4aXo2tnfd7ZsR2Jd8SXB3sF Dl6Lhsl3/rQwM3+EqFt4kdgGmY/JByxFq5X/so+Fs3KS/U+BBNlB2rhVYlXQA+1u CVKAbPT2sLw0f08L0cGs08lc+4yklYe+YcGxhf9zDg5mQ8CESaYW8XClwr6KO2Ca Bi5L7AxOidr8WOkVFscegTCwvk0HM6FxmgVLRR2ljg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=K0Erwb c25o6C5Aa71YPZgPA5xZmrfFvMUqQUgBq/dSY=; b=VG24CgFd7rmC9pX9cBtwSL NA2PGUqms5wD3afanfqeWf6wnYjNHRZJ2NJBnMltQVWKP1vG0OeskL7sa9/U0WUi G/Sx7mWyTO1WfBaiJfewCiCegmJ4MaT9nZfdz+Moz0LuTRJqHB/G2OMVeN5xsB5B FaYQYhN8jzhuscfUfTRKOlLBHVIRC9DhzaBO7qKZ7VJbwc9tmr1qdlRQqXa5SGPe pu8+SQScpMOdiSPYoMnegITQVRNkPkyX2c4eAYTfYOvEtmem+ZxOj8pbrFQnX/ip aRAATTHtSHCvUrO9zvx1/B3jyxNb+OkadUdIea5eZhrtKX5MBpvOV3YNdOQh5lYg ==
X-ME-Sender: <xms:2t5TYAWGlf_T5mkUdn_9JHH2swjgNLJzMDTQdIiQ0C-zN-jCkLXRSg> <xme:2t5TYEmqpFOKOG59ZZu6ZlsaIhvCXI97uhgF-8smWL4R6KBHtDTfYHaTPME23RfNa Z7Imin-3iabiNWLu88>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefjedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehleduudehhfeiffffhf ffvdeiffejhefhiefhffehvefhhfevgeejhffgtdehffenucffohhmrghinhephhhtthhp shhprhhovhhiuggvshifhhgrthifvghnvggvugdrshhonecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv th
X-ME-Proxy: <xmx:2t5TYEZvxs52yyU802NQfBEAXca2lInsDhhXd2Dcng2qgrrMrsz_-w> <xmx:2t5TYPWw4d9Vnw1Fzi2i3BGBLTlnAj6wyiyRzLA4AFMXlutNUUnnig> <xmx:2t5TYKk6NOzMhdfLdLQhKg14H92vudvGDtIi9cqZLxfubkKPz-7ykw> <xmx:2t5TYER9TnEZOb5XxAbtbXigTfa0g9t4WfEYkR9KkmQeqRb4LHpvRA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35AB94E05A2; Thu, 18 Mar 2021 19:14:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <40db4a3b-3ad1-48f2-84ca-b9a892ebebeb@www.fastmail.com>
In-Reply-To: <7599.1616072958@localhost>
References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <7599.1616072958@localhost>
Date: Fri, 19 Mar 2021 10:14:14 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: secdispatch@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/I4pdzpgzsnco0w3yDf3MAPXhrow>
Subject: Re: [Secdispatch] Oblivious HTTP charter draft
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: Thu, 18 Mar 2021 23:14:37 -0000

Thanks for the response Michael,

On Fri, Mar 19, 2021, at 00:09, Michael Richardson wrote:
> It seems weird that TLS is not mentioned :-)

It doesn't mention IP either.  Maybe we can just take TLS as read.
 
>     > The working group will define a format for any encryption keys that are
>     > needed. The working group will not describe how encryption keys are
>     > obtained.
> 
> My understanding is that we don't need new infrastructure, because HTTPS
> provides what we need.  So I think this text is unnecessary.

Maybe the draft isn't clear enough on this point.  For reasons described in draft-wood-key-consistency, key acquisition is not that simple.  The draft does mention HTTPS, but carefully avoids specifying its use.  I think that this bit of scope-limiting is critical.
 
> I think that there may be push in the WG to provide some extension to allow
> the proxy to snoop on, but not modify, the traffic.
> It may be worth coding this into the charter as out of scope.

I thought that "Encryption ensures that the proxy is unable to read requests or responses." was pretty clear on this point.  FWIW, I think that the IETF has been pretty good at resisting attempts to remove essential protections in our protocols.  I don't see a need to codify that in a charter; it would say more about our lack of confidence than it would affect outcomes.