Last Call Review of draft-ietf-privacypass-protocol-12
review-ietf-privacypass-protocol-12-secdir-lc-melnikov-2023-08-29-00

Reviewer: Alexey Melnikov
Review result: Ready with nits

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 with the intent of improving
security requirements and considerations in IETF drafts. Comments
not addressed in last call may be included in AD reviews during the
IESG review. Document editors and WG chairs should treat these
comments just like any other last call comments.

The Privacy Pass protocol provides a privacy-preserving authorization
mechanism.  In essence, the protocol allows clients to provide
cryptographic tokens that prove nothing other than that they have
been created by a given server in the past
<https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture>.

This document describes the issuance protocol for Privacy Pass built
on HTTP.  It specifies two variants: one that is privately
verifiable using the issuance private key based on the oblivious
pseudorandom function from <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21>,
and one that is publicly verifiable using the issuance public key based on
the blind RSA signature scheme
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-14>.

The document is well written and easy to understand. It relies on properties
of underlying mechanisms (OPRF/Blind RSA) and also references the PrivacyPass Architecture
draft. So assuming these properties hold there are no extra security or privacy
concerns to discuss in this document.

Nits:

Section 7 (Security considerations) says:
   In particular, Section 4 and
   Section 5 of [ARCHITECTURE] discuss relevant privacy considerations.

Do you really mean section 4 and 5?
In the Architecture document I see:

   4.  Deployment Models
   5.  Deployment Considerations
   6.  Privacy Considerations

So at least the reference to Section 6 seems to be missing.

In Sections 8.3.1-8.3.3 the media type registration template field
"Applications that use this media type" has the value "N/A".
This field should be describing intended use of these media types,
even if there is none at the moment. This field is intended to help
implementors decide whether or not they need to support a particular
media type, so having it as "N/A" is unhelpful.