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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
