[Ohttp] Zaheduzzaman Sarker's Block on charter-ietf-ohttp-00-00: (with BLOCK)

Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> Thu, 17 June 2021 10:47 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 61D903A1961; Thu, 17 Jun 2021 03:47:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zaheduzzaman Sarker 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.32.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Message-ID: <162392685980.9639.17048456192736231833@ietfa.amsl.com>
Date: Thu, 17 Jun 2021 03:47:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/OgxzcM7kYEQCAL_DiKIODeIn8cI>
Subject: [Ohttp] Zaheduzzaman Sarker's Block on charter-ietf-ohttp-00-00: (with BLOCK)
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: Thu, 17 Jun 2021 10:47:41 -0000

Zaheduzzaman Sarker has entered the following ballot position for
charter-ietf-ohttp-00-00: Block

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/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I was not able to follow the discussions that led to this charter text, hence
my thoughts are entirely based on the current charter text written.

I would like to discuss the followings before we go forward with external
review -

**  The client is responsible for creating the request and the information it
shares with the server. I didn't find any hint in the charter about the work
needed to actually inform or configure the client to restrict the use of
sensitive client information in the requests. I get a feel that the  current
charter is more focused on communication security and method to invoke the
communication security, which kind of not really solving the actual problem of
preventing the client information sharing with servers.

** From the charter text it is not clear what are the particular settings that
will invoke the use of ohttp, didn't got any single example to get the context
correct. This kind of making the scope of the working group a bit fuzzy, like
Rob wrote, not sure if this is a general http related work or there is a
particular usecase in mind. I think the charter should be more clear about the
context and use case if this is targeting a particular setting of http usage. I
am sure there are known cases where ohttp make sense, we just need to print
them in the charter  text.

** I believe, the linkablity cannot be solved at a particular protocol stack
level. Like the source address can be shared with the server in different ways.
Oblivious HTTP, likely to play a part at application layer but work need to be
done in the lower layer as well. I think it would need to discuss the potential
relations with other protocols that might be used with HTTP to achieve what is
desired here. The charter should acknowledge such relation very briefly and
should state if those work needed in lower layer is within scope or not.

** I am missing milestones.