Re: [Last-Call] Last call feedback on draft-ietf-ohai-ohttp-05

Mark Nottingham <mnot@mnot.net> Thu, 01 December 2022 22:18 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AC8C14CE52 for <last-call@ietfa.amsl.com>; Thu, 1 Dec 2022 14:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=mnot.net header.b=WkhO1lS0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vADAjXYO
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 0wmccjk-R8kX for <last-call@ietfa.amsl.com>; Thu, 1 Dec 2022 14:18:40 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 71193C14F6EB for <last-call@ietf.org>; Thu, 1 Dec 2022 14:18:40 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0E94D3200979; Thu, 1 Dec 2022 17:18:38 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Dec 2022 17:18:39 -0500
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=fm2; t=1669933118; x= 1670019518; bh=U2xLaPSEaIYOAsC2FHVhRQV4ZnoGHK7KNWLAWscmxVI=; b=W khO1lS0DUHMvZOn1UhPK4x+9RTStVZs1qmWp3MrN7z02E2W4x84ls+FxQac2Z4oh lY52ooa5a6HNlfPIFs/Hnik/4kGB/zqWyGy9m5TOqIuuT+svhwpm2VfZeebvpDTa 1JIFdbwXQXbBOq7rqIRiFMaBez/wypykXeMUuzo7ntEx/63AmUn37uCIWAdRu2Qf fpHiiaXeXkD5nA7YVWzBsHs5tmYtpml6IRdcJyg4q6jQDJYcJz9bMFQLpQ2ztYOk xrMs2+8fDFag1kJoAjDZfPYLEg6vDk/Qxdb+VJrrrNpz36hUAbbegxI+9toBptv0 NDVkLiSaRxPaPamQ+IfTQ==
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=fm1; t=1669933118; x= 1670019518; bh=U2xLaPSEaIYOAsC2FHVhRQV4ZnoGHK7KNWLAWscmxVI=; b=v ADAjXYOFOa1B7Po4HUtphm0m2rslL+JPCtGUMwSf3SqlptQCM7KT8E61RAL3Wt0c BnvP9g+5cutG1y4WpDejjPpqMjhkSQT8dszrxNJQv2glF1jtkfLqKZUipSWFROIR nBCfK+GgRBEY5m6Ral+KhDTvlQt60E1EvumjdPxoxSxxDdqxQVuY48XC+gE1MAKJ c/Ws6203z2Pgdszzat/A3w813RvgjAW0SbGCyVn/BW7Y/jnIXupbxD8buCt8+Zly Z+tHPziPjlN3cMQK+L9RGyrukdaGcAbE9zlq+xyRvqPplN2Mr3m4T8nJFppH1K7X xQaRtUjXj7S4fDhpicydA==
X-ME-Sender: <xms:PiiJYwy1ry3cR8fnuFHMYEcFKJo-Z002L7CMVFLeP-IGJkjvkg_jAA> <xme:PiiJY0T6fufOS1YTJAHVasT0pcDzkevx3ww_3NkXORPJWmaxQw2nUI--rH_3L1fRW pDqEAQjVgCM21jdog>
X-ME-Received: <xmr:PiiJYyX_-UtvD1wrq91_SezOC4XytlJ7pTBWRQvdKsNVr4U1F0eidqNysUG3s3a1R34-ZIT1siWfKNJ83H8krgJqz28qBjb7Oi35LhPu3VqBdJClgVv6zhXo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrtdehgdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepudetueefheegveevffdttddtieehheeiudfhgefhfeejgeefgfejhffgjedu veffnecuffhomhgrihhnpegrphhrohighigrshhlohhnghgrshgrfhgvfigtohhnshhtrh grihhnthhsrghrvghosghsvghrvhgvugdrshhopdhmnhhothdrnhgvthdpihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:PiiJY-hMrIW9UezDw0HcJbcI0hsKghGTA4GADHhIWikkHP-dkEjzUg> <xmx:PiiJYyDzmAksDA_pjwq6WqyBbJsQjiaNQFkCdsO91p7GIou9SwvM3A> <xmx:PiiJY_Lg9OLVZGvXfgp-kNg9aOdICxqOlI4ORm8alLSKTEexNktOwQ> <xmx:PiiJY1NEI_yRmLd74DdV1qiH1A83Ndflr7G0OdPuAsjQwuzqqLNXDg>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 1 Dec 2022 17:18:36 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <2302F2C4-BB02-46EC-8795-873C0675224F@mnot.net>
Date: Fri, 02 Dec 2022 09:18:12 +1100
Cc: Last Call <last-call@ietf.org>, Martin Thomson <mt@lowentropy.net>, Christopher Wood <caw@heapingbits.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <50713BBB-687E-461D-8B47-084113FE3A6F@mnot.net>
References: <2302F2C4-BB02-46EC-8795-873C0675224F@mnot.net>
To: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/4oIa0-27Y35h4_9fXdTs82xs4Uw>
Subject: Re: [Last-Call] Last call feedback on draft-ietf-ohai-ohttp-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2022 22:18:45 -0000

Also - consider not capitalising 'client' as well.

Cheers,


> On 30 Nov 2022, at 2:38 pm, Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> Technically this document looks good; my feedback is merely about editorial issues and terminology. 
> 
> 
> * This paragraph in the introduction doesn't really do the required work, and is slightly misleading (e.g., a relay resources doesn't process the messages or use HPKE).
> 
> OLD:
> 
> This document defines two kinds of HTTP resources -- Oblivious Relay Resources and Oblivious Gateway Resources -- that process encapsulated binary HTTP messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). They can be composed to protect the content of encapsulated requests and responses, thereby separating the identity of a requester from the request.
> 
> NEW:
> 
> To overcome these limitations, this document defines how encapsulated binary HTTP messages [BINARY] can be encrypted using Hybrid Public Key Encryption (HPKE; [HPKE]) to protect their contents. Clients exchange these messages with an Oblivious Gateway Resource, which is responsible for forwarding unencrypted requests to the original Target Resource and encrypting the corresponding responses and sending them back to the client. Critically, the encrypted, encapsulated messages are sent through a separate Oblivious Relay Resource to avoid exposing the client's IP address or allowing the connection to be used as a correlator between its requests. 
> 
> OLD:
> 
> Although this scheme requires support for two new kinds of oblivious resources, it represents a performance improvement over options that perform just one request in each connection.
> 
> NEW:
> 
> Because it allows connection reuse between the client and Oblivious Relay Resource, as well as between that relay and the Oblivious Gateway Resource, this scheme represents a performance improvement over using just one request in each connection.
> 
> 
> * The term 'Obvivious Relay Resource' is a bit odd. Section 6.2 admits that it can be a normal HTTP intermediary (i.e. a proxy) as long as a few constraints are observed. So, it doesn't need to be a resource. I know that's the fashion with the MASQUE folks, but I'd suggest that this just be called an 'Oblivious Relay'  -- or, indeed, 'Oblivious Proxy'.
> 
> 
> * The capital 'T' in 'Target Resource' creates a new concept and arguably causes confusion -- see e.g., draft-wood-ohai-unreliable-ohttp:
> 
>> A typical HTTP transaction consists of a request and response between a Client and Target Resource.
> 
> HTTP has no concept of a 'Target Resource'; it's just a 'resource' (see 9110 3.1). An easy fix would just be to use lowercase 'target'. I'd also consider lowercasing 'resource' throughout.
> 
> 
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

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