"TLS connections" and whether the use of HTTPS is a requirement

[LPardue]

The document uses the term TLS connection(s) in four places:

However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS connection to avoid the connection itself being used to correlate behavior.

An Oblivious Relay Resource terminates TLS connections from clients, so they see message boundaries.

Even if server keys are compromised, an adversary cannot access messages exchanged by the client with the Oblivious Relay Resource as messages are protected by TLS. Use of a compromised key also requires that the Oblivious Relay Resource cooperate with the attacker or that the attacker is able to compromise these TLS connections.

Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.

My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care.

Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-03.html#name-client-responsibilities states many requirements but not the use of HTTPS. That seems implicit via https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-03.html#name-traffic-analysis

This document assumes that all communication between different Oblivious Client, Oblivious Relay Resource, and Oblivious Gateway Resource is protected by HTTPS.

However, that seems in conflict with https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-03.html#name-server-responsibilities, which says

Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker.

In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.