[Ohttp] Benjamin Kaduk's No Objection on charter-ietf-ohttp-00-02: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 25 August 2021 21:26 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ohttp@ietf.org
Delivered-To: ohttp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD23A11BA; Wed, 25 Aug 2021 14:26:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: ohttp-chairs@ietf.org, ohttp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162992678842.24698.5716795188321150760@ietfa.amsl.com>
Date: Wed, 25 Aug 2021 14:26:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/2cOMjBGeugmDWiR0qE8Yits7Lls>
Subject: [Ohttp] Benjamin Kaduk's No Objection on charter-ietf-ohttp-00-02: (with COMMENT)
X-BeenThere: ohttp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Oblivious HTTP <ohttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohttp>, <mailto:ohttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohttp/>
List-Post: <mailto:ohttp@ietf.org>
List-Help: <mailto:ohttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohttp>, <mailto:ohttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 21:26:30 -0000
Benjamin Kaduk has entered the following ballot position for charter-ietf-ohttp-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ohttp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The new introductory paragraphs are really good; thank you for the rewrite! I don't think that just using "encryption scheme" as a shorthand for "not new cryptographic primitives" is very effective; we should probably say something else about "encryption <something-else>"s that are approved by the CFRG/etc. However, if the proxy and server collude, then neither of these privacy properties hold. I'd consider saying something about how both client and server have to have trust in the proxy to behave properly (though exactly what they're trusting the proxy to (not) do is slightly different for client and server). It's less clear whether it's useful to say something here about how a colluding client and proxy can attack the server. Examples include DNS queries, data or telemetry submission, [...] "data submission" seems pretty vague/broad in a way that "telemetry data submission" does not. the relationship between client, server, and cooperating proxy is typically configured out-of-band. Is "is typically" really appropriate given that OHTTP doesn't really exist yet? The working group will define any encryption scheme necessary and supporting data formats for carrying encapsulated requests and responses, plus any key configuration that might be needed to use the protocol. Is "key configuration" meant to encompass (abstract) data structures, data formats, and/or protocols that convey those data objects?
- [Ohttp] Benjamin Kaduk's No Objection on charter-… Benjamin Kaduk via Datatracker
- Re: [Ohttp] Benjamin Kaduk's No Objection on char… Martin Thomson