[Last-Call] Last call feedback on draft-ietf-ohai-ohttp-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Technically this document looks good; my feedback is merely about editorial issues and terminology. 


* This paragraph in the introduction doesn't really do the required work, and is slightly misleading (e.g., a relay resources doesn't process the messages or use HPKE).

OLD:

This document defines two kinds of HTTP resources -- Oblivious Relay Resources and Oblivious Gateway Resources -- that process encapsulated binary HTTP messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). They can be composed to protect the content of encapsulated requests and responses, thereby separating the identity of a requester from the request.

NEW:

To overcome these limitations, this document defines how encapsulated binary HTTP messages [BINARY] can be encrypted using Hybrid Public Key Encryption (HPKE; [HPKE]) to protect their contents. Clients exchange these messages with an Oblivious Gateway Resource, which is responsible for forwarding unencrypted requests to the original Target Resource and encrypting the corresponding responses and sending them back to the client. Critically, the encrypted, encapsulated messages are sent through a separate Oblivious Relay Resource to avoid exposing the client's IP address or allowing the connection to be used as a correlator between its requests. 

OLD:

Although this scheme requires support for two new kinds of oblivious resources, it represents a performance improvement over options that perform just one request in each connection.

NEW:

Because it allows connection reuse between the client and Oblivious Relay Resource, as well as between that relay and the Oblivious Gateway Resource, this scheme represents a performance improvement over using just one request in each connection.


* The term 'Obvivious Relay Resource' is a bit odd. Section 6.2 admits that it can be a normal HTTP intermediary (i.e. a proxy) as long as a few constraints are observed. So, it doesn't need to be a resource. I know that's the fashion with the MASQUE folks, but I'd suggest that this just be called an 'Oblivious Relay'  -- or, indeed, 'Oblivious Proxy'.


* The capital 'T' in 'Target Resource' creates a new concept and arguably causes confusion -- see e.g., draft-wood-ohai-unreliable-ohttp:

> A typical HTTP transaction consists of a request and response between a Client and Target Resource.

HTTP has no concept of a 'Target Resource'; it's just a 'resource' (see 9110 3.1). An easy fix would just be to use lowercase 'target'. I'd also consider lowercasing 'resource' throughout.





--
Mark Nottingham   https://www.mnot.net/

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux