Skip to main content

Last Call Review of draft-ietf-privacypass-protocol-12

Request Review of draft-ietf-privacypass-protocol
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-08-31
Requested 2023-08-17
Authors Sofia Celi , Alex Davidson , Steven Valdez , Christopher A. Wood
I-D last updated 2023-08-29
Completed reviews Artart Last Call review of -12 by Yoshiro Yoneya (diff)
Secdir Last Call review of -12 by Alexey Melnikov (diff)
Opsdir Last Call review of -12 by Susan Hares (diff)
Httpdir Last Call review of -12 by Mark Nottingham (diff)
Assignment Reviewer Alexey Melnikov
State Completed
Request Last Call review on draft-ietf-privacypass-protocol by Security Area Directorate Assigned
Posted at
Reviewed revision 12 (document currently at 16)
Result Has nits
Completed 2023-08-29
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

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 <>,
and one that is publicly verifiable using the issuance public key based on
the blind RSA signature scheme

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.


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.