Last Call Review of draft-ietf-ohai-ohttp-05
review-ietf-ohai-ohttp-05-secdir-lc-melnikov-2022-12-08-00

Reviewer: Alexey Melnikov
Review result: Ready with nits

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area 
directors.
Document editors and WG chairs should treat these comments just like any 
other
last call comments.

This is a well written document and it was a pleasure to read. The 
Security and Privacy Considerations sections are extensive, and trust 
relationships between actors are clearly explained.

Some nits/comments:

It looks that the term "server" sometimes means the target server and 
sometimes the Oblivious Gateway. I think this creates a bit of confusion 
when reading the document.


|4.4.  Encapsulation of Responses
|
|   Given an HPKE context context, a request message request, and a

I wish the document used a convention for variables/fields to make 
reading of paragraphs like this a bit easier. Maybe put them in quotes?

|   response response, servers generate an Encapsulated Response
|   enc_response as follows:
|
|   1.  Export a secret secret from context, using the string "message/
|       bhttp response" as context.  The length of this secret is max(Nn,
|       Nk), where Nn and Nk are the length of AEAD key and nonce
|       associated with context.  Note: Section 4.6 discusses how
|       alternative message formats might use a different context value.



6.7.  Post-Compromise Security

    This design does not provide post-compromise security for responses.

    A Client only needs to retain keying material that might be used

Nit: "to" missing after "used"?

    compromise the confidentiality and integrity of a response until that
    response is consumed, so there is negligible risk associated with a
    Client compromise.



In Section 7:

    Client privacy depends on having each configuration used by many
    other Clients.  It is critical prevent the use of unique Client

Nit: I think "to" is missing before "prevent"

    configurations, which might be used to track of individual Clients,
    but it is also important to avoid creating small groupings of Clients
    that might weaken privacy protections.


The following comment is with my Media Type reviewer hat on and it 
applies to all 3 section 9.1, 9.2 and 9.3. Using section 9.3 as an example:

9.3.  message/ohttp-res Media Type

    The "message/ohttp-res" identifies an encrypted binary HTTP response.
    This is a binary format that is defined in Section 4.4.

The above should be included into the "Applications that use this media 
type" field of the registration template,
as it helps to distinguish 3 nearly identical Media Type registration 
requests, if one only sees the extracted IANA registration templates and 
not this document.

    Type name:  message
    Subtype name:  ohttp-res
    Required parameters:  N/A
    Optional parameters:  None
    Encoding considerations:  only "8bit" or "binary" is permitted

You can't limit which encodings are used in a registration. As the 
format is binary, you should just include a single choice "binary" here.

    Security considerations:  see Section 6
    Interoperability considerations:  N/A
    Published specification:  this specification
    Applications that use this media type:  Oblivious HTTP and
       applications that use Oblivious HTTP


Best regards,
Alexey