Hey Sean, Sorry for the delay; been busy. On Wed, Nov 30, 2022, at 07:37, Sean Turner via Datatracker wrote: > 1. Is “intercept” the right word in the following text from s3: > > In order to ensure that Clients do not encapsulate > messages that other entities can intercept, the key configuration > MUST be authenticated and have integrity protection. > > I do not usually think of authentication and integrity as a mitigation against > interception. Maybe it’s that it just can’t be encrypted it must use AEAD? Or, > maybe I missed something. This is correct, I believe. Authentication and integrity protection here apply to the public keys that the gateway advertises. If an attacker is able to substitute these keys, then the client would encrypt toward a public key the attacker controls. The attacker is then be able to decrypt messages from any client that used their falsified keys. Note that clients might also rely on similar configuration for discovering the relay, so in a likely scenario the attacker can substitute both the gateway key and relay URL to ensure that the client delivers messages directly that they can decrypt. > 2. The text in s6.5 about the Client and Oblivious Relay not automatically > attempting a retry makes me wonder if this protocol is applicable only to > HTTP/2 and HTTP/3, but I know that’s not intended (see HTTP/1.1 examples)? How > is a pre-HTTP/2 client supposed to know no processing occurred? That is a good question. Easiest to answer this way: https://github.com/ietf-wg-ohai/oblivious-http/pull/222 ("HTTP/1.1 [HTTP/1.1] provides no equivalent signal.") -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
