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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Thu, 17 Jun 2021 03:47:40 -0700

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Jun 2021 09:12:36 +1000

Hi Zahed,

> preventing the client information sharing with servers.

I don't think that a charter needs to address this question.  We don't specify in HTTP charter or specifications how clients decide that a particular resource is interesting enough to request.

In this case, the draft does address the question, though obviously that could be improved through work in a working group.  Why do you think it necessary that this detail be addressed in charter?

> them in the charter  text.

I think that the discussion on other BLOCK positions has answered this already.

As above, I don't agree that charters need to carefully plot out the precise applicability of a protocol.  But ensuring that the protocol documents applicability is worthwhile.  As I noted, the draft has a section on applicability; would it help to add something explicit to the charter?  Something like:

> The OHTTP working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure.

Does that work?

> should state if those work needed in lower layer is within scope or not.

That is work that is more appropriate for a working group in the context of a protocol design.

> ** I am missing milestones.

Me too.  It happens to everyone.  I blame the pandemic.

Seriously though, I thought that Francesca had fixed this.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 18 Jun 2021 09:05:53 +0000

Hi Martin,

Responded inline below with prefix [ZS].

On 2021-06-18, 01:13, "Martin Thomson" <[email-masked]> wrote:

    Hi Zahed,

[ZS] I am not looking for any details about the answers in the charter rather clear statements on the fact that client is ultimately responsible for creating request and putting information, here in the working group we will only work on the method and encryption mechanisms needed to provide a solution for the clients who don’t want to share information with the server. I felt like this is not clearly stated in the charter and that will let others think about the question I raised. 

    As above, I don't agree that charters need to carefully plot out the precise applicability of a protocol. 

[ZS]  I believe if a working group is working on a very specific problem that should be clearly stated in the charter. It is not uncommon that people find one solution designed for a particular problem useful to solve other problems but that will not be the responsibility for this working group.

    Does that work?

[ZS]  That will work for me.

[ZS] So this is not in the scope this charter. Then I think it is better to spell it out in the charter. 

[ZS]  __, It will surely get fixed. I should have not put it my blocking statements rather in my comments, rookie AD mistake from me.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 22 Jun 2021 07:23:59 +1000

Hi Zahed,

Trimming this.

On Fri, Jun 18, 2021, at 19:05, Zaheduzzaman Sarker wrote:
> [ZS] I am not looking for any details about the answers in the charter 
> rather clear statements on the fact that client is ultimately 
> responsible for creating request and putting information, here in the 
> working group we will only work on the method and encryption mechanisms 
> needed to provide a solution for the clients who don’t want to share 
> information with the server. I felt like this is not clearly stated in 
> the charter and that will let others think about the question I raised. 

I'm having trouble parsing the first sentence here.  Are you asking for text in the charter on how a client is expected to use this protocol?  As I said before, I don't believe that's appropriate for a charter, because generating the answer to that is the work of a working group.  How a client uses the protocol depends on the shape of the protocol.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 24 Jun 2021 16:59:32 +0000

On 2021-06-21, 23:24, "Martin Thomson" <[email-masked]> wrote:

    Hi Zahed,
    Trimming this.

    > the charter and that will let others think about the question I raised. 

    I'm having trouble parsing the first sentence here.  Are you asking for text in the charter on how a client is expected to use this protocol?  As I said before, I don't believe that's appropriate for a charter, because generating the answer to that is the work of a working group.  

[ZS] In that case it is not clear if this working group or some other working group will work on the answers. I am asking for statements along the spirit of what you wrote here as it will help scoping the expectation from this working group. 

How a client uses the protocol depends on the shape of the protocol.

[ZS] agreed, but the shape of the protocol also depends on the constrains and assumptions. I expect ohttp will work on the applicability aspects and be clear on constrains and assumptions very early.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 25 Jun 2021 09:53:00 +1000

On Fri, Jun 25, 2021, at 02:59, Zaheduzzaman Sarker wrote:
> [ZS] In that case it is not clear if this working group or some other 
> working group will work on the answers. I am asking for statements 
> along the spirit of what you wrote here as it will help scoping the 
> expectation from this working group. 

I'm sorry, but I'm still not following.

It is customary for a protocol definition to describe the consequences of the design, how it is used, common patterns of abuse and the consequences of that, and other such implications.  That's what the "applicability statement" text in the charter is intended to cover.

The applicability statement for QUIC certainly covered all of that ground and more.  That's a more complicated protocol, so it has its own document.

I don't know what, specifically, more is being asked for here.

As an aside: Eliot did ask for a commitment to produce documentation on operational considerations, which is a related, but separate item and I owe him a response.