Ballot for charter-ietf-ohttp
Block
Yes
No Objection
Abstain
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
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.
I have many concerns about OHTTP (see below), which may be shared by the community. Therefore, a BoF is required before creating the WG hence my BLOCK. We may also wonder why creating a working group for a single document and whether ART is the right area but those points are details. My concerns are not all technical ones but include: 1/ What is the incentive for the proxy/request intermediaries ? 2/ Depending on 1/, we may expect that just a couple of intermediaries will exist, this leads to centralization to a couple of parties but also introduces a single point of failure, scalability issues, and easier censorship. 3/ While OHTTP would be able to 'hide' the good guys from bad networks/servers, it would also protect the bad guys who can then easily attack servers; leaving servers defenseless as they cannot protect against an attack by blocking a couple of IP addresses without also impacting the normal users. Section 8.2.1 of the I-D is a little light on the topic. Tor currently does not have the bandwidth to be a DoS vector. 4/ Related to 3/ (and perhaps less important), Law Enforcement Agencies in democratic countries will become less and less able to achieve their tasks. All in all, the points above should be discussed by the community before creating a WG. There should also be an operational consideration part.
Regarding Robert’s points, I had naïvely read the charter as being clearly for "generic oblivious HTTP mechanism to hide clients from servers”, but after looking at §3.1 (“applicability”) of draft-thomson-http-oblivious-01, I see his point: it does seem as though the author views OHTTP as being a niche, not a general, solution. The intended applicability of the work seems worth, at minimum, making more explicit in the charter, and again seems like it supports the idea of having a BOF where it can be discussed. Also, I do think it seems worth considering whether a discovery mechanism should be in-scope. On the face of it, it seems like a good idea, but maybe there's some specific reason the proponents have ruled it out. --- Here's my previous Discuss. Having read ekr's rebuttal, I was persuaded enough by his argument that this is just a special case of a previously-chartered activity, to withdraw the Block. Thanks, Éric, for some thought-provoking discussion points. My own reaction is that although they are interesting points, I don’t think business models have been seen as within the IETF’s sphere of competence (points 1 and especially 2), nor are politics (points 3 and especially 4). One can of course argue that no technology exists in a vacuum, and that all technologies have business and political ramifications, nonetheless I don’t see these as being reasonable bases for blocking progress on this proposal. Nonetheless, I do agree that these points, even though wrong ;-) may well be shared by other members of the community and that as a consequence, it’s reasonable to hold a BOF. All that said, I'm personally in favor of the work being progressed, I just think it's reasonable to make sure community input has been duly considered.
I support John, Eric, and Robert's BLOCK positions to the extent that I concur a BoF is probably warranted.
** Please provide milestones ** Editorially, it seems odd to talk about the capabilities of the "Oblivious HTTP protocol" in paragraph three, but define the protocol in paragraph four.
I support Eric's discuss position that it would be helpful to hold a BOF before chartering the WG to ensure that opinions have been heard and considered from all areas. I also find the scope of the charter to be somewhat unclear. Specifically, it isn't really clear to me whether the aim of this work is really for a generic oblivious HTTP mechanism to hide clients from servers, or whether it is really intended to be a point solution to support oblivious DNS over DoH? Some other points that a BOF could consider (particularly if this work is mostly focused on Oblivious DNS over DoH): - What it the latency performance overhead of introducing the proxies given the large number of DNS queries and given that they are performance sensitive to the end user experience? - Who is creating/managing these proxies and what trust relationship does the end user have to these proxies? - Do proxies impact the ability to do "malware detection as a service"? I.e., are there scenarios where the profiling of DNS requests coming from a particular source address is helpful for clients. - Is this technology encouraging more centralization of Internet services?
Please add milestones. I assume below is about IP addresses, hence the suggested rephrasing: - through these interactions, especially source addresses. Even without client + through these interactions, especially source IP addresses. Even without client + +++ - correlating requests from the same client over time. - ^^^ ^^ + correlating requests from the same IP address over time. + ^^^^^^^ ^^ > The OHTTP working group will define the Oblivious HTTP protocol, a method of > encapsulating HTTP requests and responses that provides protected, low-latency > exchanges. "Low-latency" isn't really capturing it, since OHTTP will most likely add some additional latency compared to a direct HTTP transaction. Maybe "that provides protected exchanges with minimal added latency"?
I support this work, although it was not easy to find a record of the discussion that kept this out of httpbis, which seems like the obvious home. I'm satisfied (via email and draft-thomson) that answers to these questions exist, but the charter could use some more explanation of the server/proxy relationship. I assume that the proxy can't see the request targets, and thus there must be a habitual relationship between the two. But these have to be controlled by independent entities to provide any privacy benefits. What server/proxy identity is the client authenticating in its own connection?