[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?