[Last-Call] Artart last call review of draft-ietf-ohai-ohttp-05

Sean Turner via Datatracker <noreply@ietf.org> Tue, 29 November 2022 20:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9981CC152597; Tue, 29 Nov 2022 12:37:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Sean Turner via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-ohai-ohttp.all@ietf.org, last-call@ietf.org, ohai@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166975427461.15718.10748282060608790716@ietfa.amsl.com>
Reply-To: Sean Turner <sean+ietf@sn3rd.com>
Date: Tue, 29 Nov 2022 12:37:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/cJMOJi8ezn_4bOsFn30yn_BB2TM>
Subject: [Last-Call] Artart last call review of draft-ietf-ohai-ohttp-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 29 Nov 2022 20:37:54 -0000

Reviewer: Sean Turner
Review result: Ready with Nits

Note I reviewed the -05 version and the editor’s diff to their working draft.

Thanks for the well written doc.  I really have only two questions and some
nits:

1. Is “intercept” the right word in the following text from s3:

  In order to ensure that Clients do not encapsulate
  messages that other entities can intercept, the key configuration
  MUST be authenticated and have integrity protection.

I do not usually think of authentication and integrity as a mitigation against
interception. Maybe it’s that it just can’t be encrypted it must use AEAD? Or,
maybe I missed something.

2. The text in s6.5 about the Client and Oblivious Relay not automatically
attempting a retry makes me wonder if this protocol is applicable only to
HTTP/2 and HTTP/3, but I know that’s not intended (see HTTP/1.1 examples)? How
is a pre-HTTP/2 client supposed to know no processing occurred?

Nits follow, but are in a
PR (https://github.com/ietf-wg-ohai/oblivious-http/pull/221):
s2: s/A Oblivious/An Oblivious
s4.3: s/request request/request, request,
s4.4:s/response response/response, response,
s4.4, step 1: s/secret secret/secret, secret,
s4.4, step 3: s/response_nonce/response_nonce.
s4.4, step 5: s/nonce nonce/nonce, nonce,
s5: s/For the request the/For the request, the
s6.2: s/HTTP, a Oblivious/HTTP, an Oblivious
s6.2:s/though it assumed to/though it is assumed
s6.3: s:/ such those/such as those
s7: s/critical prevent/critical to prevent

Hobby Horse:
When are HTTP examples going to switch to H2 or H3?