SECDIR review

draft-ietf-privacypass-architecture.md

@@ -111,7 +111,7 @@ Origins (servers). It allows Origins to challenge Clients to present tokens
 for authorization. Depending on the type of token, e.g., whether or not it
 can be cached, the Client either presents a previously obtained token or
 invokes an issuance protocol, such as
-{{?ISSUANCE=I-D.ietf-privacypass-protocol}}, to acquire a token to present as
+{{!ISSUANCE=I-D.ietf-privacypass-protocol}}, to acquire a token to present as
 authorization.
 
 This document describes requirements for both redemption and issuance
@@ -126,23 +126,47 @@ the security of all participating entities.
 The following terms are used throughout this document:
 
 Client:
-: An entity that seeks authorization to an Origin.
+: An entity that seeks authorization to an Origin. Using {{?RFC9334}} terminology,
+Clients implement the RATS Attester role.
+
+Token:
+: A cryptographic authentication message used for authorization decisions.
 
 Origin:
-: An entity that redeems tokens presented by Clients.
+: An entity that consumes tokens presented by Clients and uses them to make authorization decisions.
+
+Challenge:
+: The mechanism by which Origins request tokens from Clients.
+
+Redemption:
+: The mechanism by which Clients present tokens to Origins for consumption.
 
 Issuer:
 : An entity that issues tokens to Clients for properties
   attested to by the Attester.
 
+Issuance:
+: The mechanism by which an Issuer produces tokens for Clients.
+
 Attester:
 : An entity that attests to properties of Clients for the
-  purposes of token issuance.
+  purposes of token issuance. Using {{?RFC9334}} terminology, Attesters implement
+  the RATS Verifier role.
 
 Attestation procedure:
 : The procedure by which an Attester determines whether or not a Client
   is trusted with a specific set of properties for token issuance.
 
+Anonymization service:
+: A service through which Clients mask their IP address when connecting to other
+protocol participants, e.g., an IP-hiding proxy. In general, use of an anonymization
+service ensures that all Clients which use the service are indistinguishable from
+one another, though in practice there may be small distinguishing features (TLS
+fingerprints, HTTP headers, etc).
+
+The trust relationships between each of the entities in this list is further
+elaborated upon in {{privacy-and-trust}}.
+
 # Architecture
 
 The Privacy Pass architecture consists of four logical entities --
@@ -192,8 +216,10 @@ Token Response, the Client computes a token from the token challenge and Token
 Response. This token can be validated by anyone with the per-Issuer key, but
 cannot be linked to the content of the Token Request or Token Response.
 
-6. If the Client has a token, it includes it in a subsequent request to
-   the Origin, as authorization. This token is sent only once.  The Origin
+6. If the Client has a token, it includes it in a subsequent, retried request to
+   the Origin, as authorization. This token is sent only once in response to a
+   challenge; Clients do not send tokens more than once, even if they receive
+   duplicate or redundant challenges. The Origin
    validates that the token was generated by the expected Issuer and has not
    already been redeemed for the corresponding token challenge.  If the Client
    does not have a token, perhaps because issuance failed, the client does not
@@ -216,6 +242,10 @@ cannot be linked to the content of the Token Request or Token Response.
 ~~~
 {: #fig-overview title="Privacy pass redemption and issuance protocol interaction"}
 
+<!-- ## Use Cases
+
+XXX(caw): add use cases here -->
+
 ## Privacy Goals and Threat Model {#privacy-and-trust}
 
 The end-to-end flow for Privacy Pass described in {{overview}} involves three
@@ -256,7 +286,10 @@ issued to a Client that successfully completed attestation with an Attester
 that the Issuer trusts. Moreover, this arrangement means that if an Origin
 accepts tokens issued by an Issuer that trusts multiple Attesters, then a
 Client can use any one of these Attesters to issue and redeem tokens for the
-Origin.
+Origin. Whether or not these different entities in the architecture collude
+for learning redemption, issuance, or attestation contexts, as well as the
+necessary preconditions for context unlinkability, depends on the deployment
+model; see {{deployment}} for more details.
 
 The mechanisms for establishing trust between each entity in this arrangement
 are deployment specific. For example, in settings where Clients interact with
@@ -266,7 +299,10 @@ Clients do not communicate with Issuers through an Attester, the Attesters
 might convey this trust via a digital signature over that Issuers can verify.
 
 Clients explicitly trust Attesters to perform attestation correctly and in a
-way that does not violate their privacy. However, Clients assume Issuers and
+way that does not violate their privacy. In particular, this means that Attesters
+which may be privy to private information about Clients are trusted to not disclose
+this information to non-colluding parties; see {{deployment}} for more about different
+deployment models and non-collusion assumptions. However, Clients assume Issuers and
 Origins are malicious.
 
 Given this threat model, the privacy goals of Privacy Pass are oriented around
@@ -306,8 +342,12 @@ attestation, and issuance protocol details. For example, as discussed in
 {{deployment}}, failure to use a privacy-enhancing proxy system such as Tor
 {{DMS2004}} when interacting with Attesters, Issuers, or Origins allows
 the set of possible Clients to be partitioned by the Client's IP address, and
-can therefore lead to unlinkability violations. Similarly, malicious Origins
-may attempt to link two redemption contexts together by using Client-specific
+can therefore lead to unlinkability violations. As such, depending on the
+deployment model, Clients may need to make use of an anonymization service when
+interacting with Origin or Attester in order to maintain unlinkability. When
+such services are used, Clients trust them to not disclosure private Client
+information (such as IP addresses) to untrusted parties. Similarly, malicious
+Origins may attempt to link two redemption contexts together by using Client-specific
 Issuer public keys. See {{deployment-considerations}} and {{privacy}} for more information.
 
 The remainder of this section describes the functional properties and security
@@ -318,7 +358,7 @@ through these protocols.
 ## Redemption Protocol {#redemption}
 
 The Privacy Pass redemption protocol, described in
-{{?AUTHSCHEME=I-D.ietf-privacypass-auth-scheme}}, is an authorization protocol
+{{!AUTHSCHEME=I-D.ietf-privacypass-auth-scheme}}, is an authorization protocol
 wherein Clients present tokens to Origins for authorization. Normally,
 redemption follows a challenge-response flow, wherein the Origin challenges
 Clients for a token with a TokenChallenge ({{AUTHSCHEME, Section 2.1}}) and,
@@ -358,7 +398,7 @@ including:
 - Issuer identity. Token challenges identify which Issuers are trusted for a
   given issuance protocol. As described in {{privacy-and-trust}}, the choice
   of Issuer determines the type of Attesters and attestation procedures possible
-  for a token from the specified Issuer, but the Client does not learn exactly
+  for a token from the specified Issuer, but the Origin does not learn exactly
   which Attester was used for a given token issuance event.
 - Redemption context. Challenges can be bound to a given redemption context,
   which influences a client's ability to pre-fetch and cache tokens. For
@@ -370,16 +410,22 @@ including:
   which the challenge originated (referred to as per-Origin tokens), or
   can be used across multiple Origins (referred to as cross-Origin tokens).
   The set of Origins for which a cross-Origin token is applicable is referred
-  to as the cross-Origin set.
+  to as the cross-Origin set. Every Origin in a cross-Origin set implicitly agrees
+  to being in the set by supporting cross-Origin challenges.
 
 Origins that admit cross-Origin tokens bear some risk of allowing tokens
 issued for one Origin to be spent in an interaction with another Origin.
-In particular, depending on the use case, Origins may need to maintain
-state to track redeemed tokens. For example, Origins that accept cross-Origin
-tokens across shared redemption contexts SHOULD track which tokens have been
-redeemed already in those redemption contexts, since these tokens can
-be issued and then spent multiple times in response to any such challenge.
-See {{Section 2.1.1 of AUTHSCHEME}} for discussion.
+In particular, cross-Origin tokens issued in response to a challenge for
+one Origin can be redeemed at another Origin in the cross-Origin set,
+which can make it difficult to regulate token consumption. Depending on the
+use case, Origins may need to maintain state to track redeemed tokens. For
+example, Origins that accept cross-Origin tokens across shared redemption
+contexts SHOULD track which tokens have been redeemed already in those
+redemption contexts, since these tokens can be issued and then spent multiple
+times in response to any such challenge. Note that Clients which redeem the
+same token to multiple Origins do risk those Origins being able to link
+Client activity together, which can disincentivize this behavior. See
+{{Section 2.1.1 of AUTHSCHEME}} for discussion.
 
 How Clients respond to token challenges can have privacy implications.
 For example, if an Origin allows the Client to choose an Issuer, then the choice
@@ -442,7 +488,8 @@ detail.
 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.
+to perform attestation correctly, i.e., to implement attestation procedures
+in a way that are not subverted or bypassed by malicious Clients.
 
 {{?RFC9334}} describes an architecture for attestation procedures. Using
 that architecture as a conceptual basis, Clients are RATS attesters that
@@ -464,11 +511,10 @@ the scope of the issuance protocol. Example attestation procedures are below.
 
 Attesters may support different types of attestation procedures.
 
-In general, each attestation procedure has different security properties. For
+Each attestation procedure has different security properties. For
 example, attesting to having a valid account is different from attesting to
-running on trusted hardware. In general, minimizing the set of supported
-attestation procedures helps minimize the amount of information leaked through
-a token.
+running on trusted hardware. Supporting multiple attestation procedures is
+an important step towards ensuring equitable access for Clients; see {{discrimination}}.
 
 The role of the Attester in the issuance protocol and its impact on privacy
 depends on the type of attestation procedure, issuance protocol, deployment
@@ -555,9 +601,9 @@ generates itself, or the Issuer provides during the issuance flow and
 the client can check for correctness. Opaque public metadata is metadata
 the client can see but cannot check for correctness. As an example, the
 opaque public metadata might be a "fraud detection signal", computed on
-behalf of the Issuer, during token issuance. In normal circumstances,
-Clients cannot determine if this value is correct or otherwise a tracking
-vector.
+behalf of the Issuer, during token issuance. Generally speaking, Clients
+cannot determine if this value is generated honestly or otherwise a
+tracking vector.
 
 Private metadata is that which Clients cannot observe as part of the token
 issuance flow. Such instantiations can be built on the Private Metadata Bit
@@ -736,7 +782,7 @@ Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that
 issuance and redemption events be separated over time, such as through the use
 of tokens that correspond to token challenges with an empty redemption context
 (see {{redemption}}), or be separated over space, such as through the use of an
-anonymizing proxy when connecting to the Origin.
+anonymizing service when connecting to the Origin.
 
 ## Joint Attester and Issuer {#deploy-joint-issuer}
 
@@ -860,14 +906,18 @@ in two important ways: (1) discriminatory treatment of Clients and the viability
 of an open Web, and (2) centralization. This section describes considerations
 relevant to these topics.
 
-## Discriminatory Treatment
+## Discriminatory Treatment {#discrimination}
 
 Origins can use tokens as a signal for distinguishing between Clients
 that are capable of completing attestation with one Attester trusted by the
-Origin's chosen Issuer, and Clients that are not capable of doing the same. A
-consequence of this is that Privacy Pass could enable discriminatory treatment
-of Clients based on Attestation support. This could lead to harmful ecosystem
-effects if left unresolved.
+Origin's chosen Issuer, and Clients that are not capable of doing the same,
+either because they cannot work with a supported Attester, have disabled
+Privacy Pass support, or maybe even have not implemented the protocol. A
+consequence of this is that Privacy Pass, when used for open services on the
+Internet, could enable discriminatory treatment of Clients based on Attestation
+support. This could lead to harmful ecosystem effects if left unresolved, such
+as Attester lock-in ("walled gardens") or similar obstacles to interacting with
+otherwise open services.
 
 In principle, Issuers should strive to work with a set of Attesters that are
 suitable for all Clients, thereby mitigating such discriminatory behavior.
@@ -1009,13 +1059,13 @@ redemption context.
 # Security Considerations {#security}
 
 This document describes security and privacy requirements for the Privacy Pass
-redemption and issuance protocols. It also describes deployment models and
-privacy considerations for using Privacy Pass within those models. Ensuring
-Client privacy -- separation of attestation and redemption contexts -- requires
-active work on behalf of the Client, especially in the presence of malicious
-Issuers and Origins. Implementing mitigations discussed in {{deployment}}
-and {{privacy}} is therefore necessary to ensure that Privacy Pass offers
-meaningful privacy improvements to end-users.
+redemption and issuance protocols. It also describes deployment models built
+around non-collusion assumptions and privacy considerations for using Privacy
+Pass within those models. Ensuring Client privacy -- separation of attestation
+and redemption contexts -- requires active work on behalf of the Client,
+especially in the presence of malicious Issuers and Origins. Implementing
+mitigations discussed in {{deployment}} and {{privacy}} is therefore necessary
+to ensure that Privacy Pass offers meaningful privacy improvements to end-users.
 
 ## Token Caching {#hoarding}