jiebi/CodeConvo huggingface dataset:
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's <del> anonymity set shrinks to the total number of clients controlling </del> <ins> anonymity set shrinks to the total number of Clients controlling </ins> tokens for the same keys. In the following, we consider the possible ways that Issuers can
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: Client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the Issuer.  When an Issuer rotates their key, any Client that invokes the issuance protocol in this key <del> cycle will be part of a group of possible clients owning valid tokens </del> <ins> cycle will be part of a group of possible Clients owning valid tokens </ins> for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients.
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: partition, the Client limits the number of different Issuers used to a small number to maintain the privacy properties the Client requires.  As long as each redemption partition maintains a strong <del> privacy boundary with each other, the verifier will only be able to learn a number of bits of information up to the limits within that "redemption partition". </del> <ins> privacy boundary with the others, the number of bits of information the verifier can learn is bounded by the number of "redemption partitions". </ins> To support this strategy, the client keeps track of a "partition" which contains the set of Issuers that redemptions have been
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: 6. <del> We present a number of security considerations that prevent malicious Clients from abusing the protocol. 6.1. </del> <ins> Beyond the aforementioned security gaols for the Issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to mitigate the risk of abuse by malicious Clients. </ins> When a Client holds tokens for an Issuer, it is possible for any verifier to cause that client to redeem tokens for that Issuer.  This can lead to an attack where a malicious verifier can force a Client to spend all of their tokens from a given Issuer.  To prevent this from happening, tokens can be scoped to single Origins such that they <del> can only be redeemed within for a single Origin. </del> <ins> can only be redeemed for a single Origin. </ins> If tokens are cross-Origin, Clients should use alternate methods to prevent many tokens from being redeemed at once.  For example, if the
Code change:
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL

Related discussion:
text: directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance <del> protocol, in the original Privacy Pass protocol PPSRV, tokens were </del> <ins> protocol, in the original Privacy Pass protocol PPEXT, tokens were </ins> only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact.
Code change:
it's not crystal-clear what the interaction model for this auth scheme is. In many auth schemes, the credential is repeated on each request, to keep the protocol stateless, and to prove the client's identity. However, that doesn't seem to be desireable here -- not only would it make all of those responses uncacheable, it would (AIUI) 'spend' a lot of private tokens. OTOH, the 'realm' parameter is explicitly supported (albiet without much detail), which implies the opposite. I think the preferred interaction model is that a token is only spent upon an explicit challenge from the server, but it was difficult to discern this from the documentation. Either way, it'd be good to clarify this.
Correct, the client shouldn't spend a token multiple times, and shouldn't keep including the credential on future requests. We could drop the realm text, but I think allowing it as a MAY does leave open use cases that might want to segment up different use cases of tokens.
Yeah, unless there's a reason to omitting it, I think keeping the MAY for the realm is fine. I tried to get a sense for how clients are intended to use other auth schemes from RFC 9110, but it wasn't clear to me. NAME do you know of other auth scheme specifications that make the interaction model more clear?

Related discussion:
text: valid token available, it presents the token to the origin (redemption). <ins> Unlike many authentication schemes in which a client will present the same credentials across multiple requests, tokens used with the "PrivateToken" scheme are single-use credentials, and are not reused. Spending the same token value more than once allows the origin to link multiple transactions to the same client.  In deployment scenarios where origins send token challenges to request tokens, origins ought to expect at most one request containing a token from the client in reaction to a particular challenge. </ins> 2.1. Origins send a token challenge to clients in an "WWW-Authenticate"
Code change:
There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)

Related discussion:
text: 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 <del> been created by a given server in the past I-D.ietf-privacypass- architecture. </del> <ins> been created by a given server in the past ARCHITECTURE. </ins> This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. <del> This document DOES NOT cover the architectural framework required for running and maintaining the Privacy Pass protocol in the Internet setting.  In addition, it DOES NOT cover the choices that are necessary for ensuring that client privacy leaks do not occur.  Both of these considerations are covered in I-D.ietf-privacypass- architecture. </del> <ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks. This information is covered in ARCHITECTURE. </ins> 2.
Code change:
There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)

Related discussion:
text: blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document I-D.ietf-privacypass-architecture. </del> <ins> Architecture document ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This
Code change:
In this image: ! It isn't very clear where messages originate and who gets to see them. In particular, it isn't clear where the TokenRequest originates (the Client) and whether the Attester gets to see it (¯(°_o)/¯).
That's a fair point. It should be clear that the TokenRequest comes from the Attester. I wonder if we also somehow need to illustrate that there's a trust relationship between the Attester and Issuer here. Something to at least imply that the Attester is either implicitly trusted to do attestation, or, perhaps in future versions of Privacy Pass, attestation proofs are sent directly to the Issuer.
Move diagram to section 3 (architecture). Also move much of the second intro paragraph down. Add more text about the actual steps to section 3, such as a numbered list
In here, introduce the basic privacy premise for how the redemption and issuance contexts are separated
The architecture references [AUTHSCHEME] for key concepts far more than I expected. For instance: Or: Can the architecture define the messages in their own right, then point to [AUTHSCHEME] for example implementations?
Is the suggestion here to describe -- conceptually -- what Token and TokenChallenges are in the architecture document? If so, that seems quite reasonable.
Yeah. An architecture is most useful if you don't have to dig into the details to understand it and those references are somewhat critical to comprehension.

Related discussion:
text: identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See <del> attester-role for more details. </del> <ins> attester for more details. </ins> 3.2.1.
Code change:
The issuance overview step 3 says that the Client and Attester interact to do whatever is necessary to convince the Attester to attest. But there doesn't seem to be any pretext for this process to be initiated. Step 4 says that the client requests issuance (via the Attester), which would provide the necessary cause to start the attesting process. Should these steps be swapped?
Either the attester is an intermediary to the flow (which is what we're doing in practice), or it is a separate flow. So the prerequisite is that the client knows it wants to request a token from an issuer, and then it does attestation.
Perhaps this could be made more clear if we say that the client, upon deciding it wants to invoke the issuance protocol, then begins the deployment-specific attestation process with its trusted attester? I can suggest some text for this.

Related discussion:
text: If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step-redemption and <del> redeem its token.  Otherwise, it invokes the issuance protocol to request a token from the designated Issuer. The first step in the issuance protocol is attestation. Specifically, the Attester performs attestation checks on the Client.  These checks could be proof of solving a CAPTCHA, device trust, hardware attestation, etc (see attester). If attestation succeeds, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the details of Attestation, the Client can send the Token Request to the Attester alongside any attestation information.  If attestation fails, the Client receives an error and issuance aborts without a token. </del> <ins> redeem its token. If the Client does not have a token available and decides it wants to obtain one (or more) bound to the token challenge, it then invokes the issuance protocol.  As a prerequisite to the issuance protocol, the Client runs the deployment specific attestation process that is required for the designated Issuer.  Client attestation can be done via proof of solving a CAPTCHA, checking device or hardware attestation validity, etc; see attester for more details. If the attestation process completes successfully, the client creates a Token Request to send to the designated Issuer (generally via the Attester).  The Attester and Issuer might be functions on the same server, depending on the deployment model (see deployment).  Depending on the attestation process, it is possible for attestation to run alongside the issuance protocol, e.g., where Clients send necessary attestation information to the Attester along with their Token Request.  If the attestation process fails, the Client receives an error and issuance aborts without a token. </ins> The Issuer generates a Token Response based on the Token Request, which is returned to the Client (generally via the Attester).
Code change:
I think that this definition is incorrect. The latest sentence is from the definition of Origin-Client unlinkability:
good catch. Copy-pasta error.

Related discussion:
text: Issuer-Client unlinkability.  This is similar to Origin-Client unlinkability in that a Client in an issuance context is indistinguishable from any other Client that might use the same <del> issuance context.  The set of Clients that share the same redemption context is referred to as a redemption anonymity set. </del> <ins> issuance context.  The set of Clients that share the same issuance context is referred to as an issuance anonymity set. </ins> Attester-Origin unlinkability.  This is similar to Origin-Client and Issuer-Client unlinkability.  It means that given two attestation contexts, the Attester cannot determine if both contexts correspond to the same Origin or two different Origins. The set of Clients that share the same attestation context is <del> referred to as an anonymity set. </del> <ins> referred to as an attestation anonymity set. </ins> By ensuring that different contexts cannot be linked in this way, only the Client is able to correlate information that might be used
Code change:
NAME good suggestions! I merged them all.
This system extensively uses tokens that are only loosely bound to usage contexts. Possession of a token is pretty much all that is necessary. That means that tokens might be stolen or hoarded and then replayed. The architecture draft says nothing about this as a risk, but it probably should.
Agree, especially for for cached tokens. I thought we had mentioned this somewhere, but if not, let's make sure it's included.

Related discussion:
text: If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step-redemption and <del> redeem its token. </del> <ins> redeem its token; see hoarding for security considerations of cached tokens. </ins> If the Client does not have a token available and decides it wants to obtain one (or more) bound to the token challenge, it then
Code change:
NAME good suggestions! I merged them all.
This system extensively uses tokens that are only loosely bound to usage contexts. Possession of a token is pretty much all that is necessary. That means that tokens might be stolen or hoarded and then replayed. The architecture draft says nothing about this as a risk, but it probably should.
Agree, especially for for cached tokens. I thought we had mentioned this somewhere, but if not, let's make sure it's included.

Related discussion:
text: Origins.  Implementing mitigations discused in deployment and privacy is therefore necessary to ensure that Privacy Pass offers meaningful privacy improvements to end-users. <ins> 7.1. Depending on the Origin's token challenge, Clients can request and cache more than one token using an issuance protocol.  Cached tokens help improve privacy by separating the time of token issuance from the time of token redemption, and also allow Clients to reduce the overhead of receiving new tokens via the issuance protocol. As a consequence, Origins that send token challenges which are compatible with cached tokens need to take precautions to ensure that tokens are not replayed.  This is typically done via keeping track of tokens that are redeemed for the period of time in which cached tokens would be accepted for particular challenges. Moreover, since tokens are not intrinsically bound to Clients, it is possible for malicious Clients to collude and share tokens in a so- called "hoarding attack."  As an example of this attack, many distributed Clients could obtain cacheable tokens and them share them with a single Client to redeem in a way that would violate an Origin's attempt to limit tokens to any one particular Client. Depending on the deployment model, it can be possible to detect these types of attacks by comparing issuance and redemption contexts; for example, this is possible in the Joint Origin and Issuer model. </ins>
Code change:
In a successful issuance exchange, the attester provides the issuer with information about the client. The text in Section 3.2.1 points out that the way in which information about the client is combined could reduce anonymity set size in ways that affect privacy. Given that we have a chain of custody, I imagine that the privacy property here is about what the issuer learns about a client. More information means more information that might then propagate from the issue onward to the origin. This means that the attester needs to limit what it passes along to only that which is relevant. The client needs to trust the attester to do this. ... or does it? The text in Section 3.2.1 implies strongly that this anonymity set size is important, but the constraints on the client-issuer interaction, especially consistency rules, very much limits what the issuer can pass along to the origin. So maybe the system depends less on trusting the attester and more on the combination of the cryptographic properties of the token and the consistency system that mitigates against misuse. None of this appears in the privacy considerations. Should it?
On this point: "Clients do not explicitly trust Issuers." (Section 3.2.2) This would invalidate much of the discussion of anonymity sets in attestations. This is quite confusing. The client doesn't need to trust the issuer, because the issuer is unable to pass information on to others. However, the client cannot trust the issuer with information, so it has to trust the attester not to pass stuff along AND it has to use an anonymizing proxy to interact with the issuer so that nothing leaks. This is quite contradictory overall.
There are issuance protocols wherein the issuer learns information about the origin by design, like the . In this variant, if the attester were to pass information about the client on to the issuer, then the issuer would be able to reconstruct the (client, origin) pair, breaking the unlinkability goals. I agree that in the case where the issuer learns nothing about the origin in the protocol then reliance on the attester is lessened, but we need to make sure we accommodate future issuance protocols here. I'll think about ways in which we can try to make this more clear. This might go into the privacy considerations, as suggested.

Related discussion:
text: 3.4.1. <del> Attestation is an important part of the issuance protocol.  In Privacy Pass, attestation is the process by which an Attester bears witness to, confirms, or authenticates a Client so as to verify a property about the Client that is required for Issuance.  Clients explicitly trust Attesters to perform attestation correctly and in a way that does not violate their privacy. </del> <ins> In Privacy Pass, attestation is the process by which an Attester bears witness to, confirms, or authenticates a Client so as to verify properties about the Client that are required for Issuance.  Issuers trust Attesters to perform attestation correctly. </ins> RFC9334 describes an architecture for attestation procedures.  Using that architecture as a conceptual basis, Clients are RATS attesters
Code change:
8445 8174 Future documents, not future versions Fix normative refs
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
LGTM

Related discussion:
text: WebRTC IP Address Handling Requirements <del> draft-ietf-rtcweb-ip-handling-10 </del> <ins> draft-ietf-rtcweb-ip-handling-11 </ins> Abstract