draft-ietf-privacypass-http-api-00.txt   draft-ietf-privacypass-http-api-01.txt 
Network Working Group S. Valdez Network Working Group S. Valdez
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Informational 5 January 2021 Intended status: Informational 12 July 2021
Expires: 9 July 2021 Expires: 13 January 2022
Privacy Pass HTTP API Privacy Pass HTTP API
draft-ietf-privacypass-http-api-00 draft-ietf-privacypass-http-api-01
Abstract Abstract
This document specifies an integration for Privacy Pass over an HTTP This document specifies an integration for Privacy Pass over an HTTP
API, along with recommendations on how key commitments are stored and API, along with recommendations on how key commitments are stored and
accessed by HTTP-based consumers. accessed by HTTP-based consumers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at line 31 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 July 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Layout 1.2. Layout . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Requirements 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. Privacy Pass HTTP API Wrapping 2. Privacy Pass HTTP API Wrapping . . . . . . . . . . . . . . . 3
3. Server key registry 3. Server key registry . . . . . . . . . . . . . . . . . . . . . 3
3.1. Key Registry 3.1. Key Registry . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Server Configuration Retrieval 3.2. Server Configuration Retrieval . . . . . . . . . . . . . 5
4. Key Commitment Retrieval 4. Key Commitment Retrieval . . . . . . . . . . . . . . . . . . 5
5. Privacy Pass Issuance 5. Privacy Pass Issuance . . . . . . . . . . . . . . . . . . . . 7
6. Privacy Pass Redemption 6. Privacy Pass Redemption . . . . . . . . . . . . . . . . . . . 8
6.1. Generic Token Redemption 6.1. Generic Token Redemption . . . . . . . . . . . . . . . . 8
6.2. Direct Redemption 6.2. Direct Redemption . . . . . . . . . . . . . . . . . . . . 9
6.3. Delegated Redemption 6.3. Delegated Redemption . . . . . . . . . . . . . . . . . . 10
7. Security Considerations 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Well-Known URI 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References 9.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 11
Author's Address 10. Normative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Privacy Pass protocol as described in The Privacy Pass protocol as described in
[draft-davidson-pp-protocol] can be integrated with a number of [draft-ietf-privacypass-protocol] can be integrated with a number of
different settings, from server to server communication to browsing different settings, from server to server communication to browsing
the internet. the internet.
In this document, we will provide an API to use for integrating In this document, we will provide an API to use for integrating
Privacy Pass with an HTTP framework. Providing the format of HTTP Privacy Pass with an HTTP framework. Providing the format of HTTP
requests and responses needed to implement the Privacy Pass protocol. requests and responses needed to implement the Privacy Pass protocol.
1.1. Terminology 1.1. Terminology
We use the same definition of server and client that is used in We use the same definition of server and client that is used in
[draft-davidson-pp-protocol] and [draft-davidson-pp-architecture]. [draft-ietf-privacypass-protocol] and
[draft-ietf-privacypass-architecture].
We assume that all protocol messages are encoded into raw byte format We assume that all protocol messages are encoded into raw byte format
before being sent. We use the TLS presentation language [RFC8446] to before being sent. We use the TLS presentation language [RFC8446] to
describe the structure of protocol messages. describe the structure of protocol messages.
1.2. Layout 1.2. Layout
* Section 2: Describes the wrapping of messages within HTTP * Section 2: Describes the wrapping of messages within HTTP
requests/responses. requests/responses.
skipping to change at line 190 skipping to change at page 5, line 11
that the key material is owned by the server. This requires that the that the key material is owned by the server. This requires that the
client know the public verification key that is associated with the client know the public verification key that is associated with the
server. server.
To avoid user segregation as a result of server configuration/ To avoid user segregation as a result of server configuration/
commitment rotation, the log operator SHOULD enforce limits on how commitment rotation, the log operator SHOULD enforce limits on how
many active commitments exist and how quickly the commitments are many active commitments exist and how quickly the commitments are
being rotated. Clients SHOULD reject configurations/commitments that being rotated. Clients SHOULD reject configurations/commitments that
violate their requirements for avoiding user segregation. These violate their requirements for avoiding user segregation. These
considerations are discussed as part of considerations are discussed as part of
[draft-davidson-pp-architecture]. [draft-ietf-privacypass-architecture].
3.2. Server Configuration Retrieval 3.2. Server Configuration Retrieval
Inputs: - "server_origin": The origin to retrieve a server Inputs: - "server_origin": The origin to retrieve a server
configuration for. configuration for.
No outputs. No outputs.
1. The client makes an anonymous GET request to 1. The client makes an anonymous GET request to
"CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type "CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type
skipping to change at line 277 skipping to change at page 6, line 49
} }
1. The client then verifies the signature for each key commitment 1. The client then verifies the signature for each key commitment
and stores the list of commitments to the current scope. The and stores the list of commitments to the current scope. The
client SHOULD NOT cache the commitments beyond the current scope, client SHOULD NOT cache the commitments beyond the current scope,
as new commitments should be fetched for each independent as new commitments should be fetched for each independent
issuance and redemption request. The client SHOULD verify the issuance and redemption request. The client SHOULD verify the
"inclusion_proofs" to confirm that the key commitment has been "inclusion_proofs" to confirm that the key commitment has been
submitted to a trusted registry. Once the client receives the submitted to a trusted registry. Once the client receives the
"ciphersuite" for the server, it should implement all Privacy "ciphersuite" for the server, it should implement all Privacy
Pass API functions (as detailed in [draft-davidson-pp-protocol]) Pass API functions (as detailed in
using this ciphersuite. [draft-ietf-privacypass-protocol]) using this ciphersuite.
5. Privacy Pass Issuance 5. Privacy Pass Issuance
Inputs: - "server_origin": The origin to request token issuance from. Inputs: - "server_origin": The origin to request token issuance from.
- "count": The number of tokens to request issuance for. - "count": The number of tokens to request issuance for.
Outputs: - "tokens": A list of tokens that have been signed via the Outputs: - "tokens": A list of tokens that have been signed via the
Privacy Pass protocol. Privacy Pass protocol.
1. When a client wants to request tokens from a server, it should 1. When a client wants to request tokens from a server, it should
skipping to change at line 335 skipping to change at page 8, line 13
Privacy Pass API. Privacy Pass API.
6. Privacy Pass Redemption 6. Privacy Pass Redemption
There are two forms of Privacy Pass redemption that could function There are two forms of Privacy Pass redemption that could function
under the HTTP API. Either passing along a token directly to the under the HTTP API. Either passing along a token directly to the
target endpoint, which would perform its own redemption Section 6.1, target endpoint, which would perform its own redemption Section 6.1,
or the client redeeming the token and passing the result along to the or the client redeeming the token and passing the result along to the
target endpoint. These two methods are described below. target endpoint. These two methods are described below.
In the HTTP ecosystem, redemption contexts should generally be keyed
by the same privacy boundary used for cookies and other local
storage. Generally this is the top-level origin. Any redemption
context should be built following the principles outlined in
[draft-ietf-privacypass-architecture] and later in Section 8.
6.1. Generic Token Redemption 6.1. Generic Token Redemption
Inputs: - "server_id": The server ID to redeem a token against. - Inputs: - "context": The request context to use. - "server_id": The
"ciphersuite": The ciphersuite for this token. - "public_key": The server ID to redeem a token against. - "ciphersuite": The ciphersuite
public key associated with this token. - "redemption_token": A for this token. - "public_key": The public key associated with this
Privacy Pass token. - "info": Additional data to bind to this token token. - "redemption_token": A Privacy Pass token. - "info":
redemption. Additional data to bind to this token redemption.
Outputs: - "result": The result of the redemption from the server. Outputs: - "result": The result of the redemption from the server.
1. The client should call the "Redeem" function with 1. The client should check whether the "server_id" is present in the
"context". If it isn't and the size of the "context" is beneath
the client's limit, it should be added.
2. The client should call the "Redeem" function with
"redemption_token" and additional data of "info" storing the "redemption_token" and additional data of "info" storing the
resulting "data" and "tag". resulting "data" and "tag".
2. The client makes a POST request to <"server_origin">/.well-known/ 3. The client makes a POST request to <"server_origin">/.well-known/
privacy-pass with a message of type "token-redemption" and a body privacy-pass with a message of type "token-redemption" and a body
of: of:
struct { struct {
opaque server_id<1..2^16-1> = server_id; opaque server_id<1..2^16-1> = server_id;
opaque data<1..2^16-1> = data; opaque data<1..2^16-1> = data;
opaque tag<1..2^16-1> = tag; opaque tag<1..2^16-1> = tag;
opaque info<1..2^16-1> = info; opaque info<1..2^16-1> = info;
} }
skipping to change at line 381 skipping to change at page 9, line 22
// the server's verification key. // the server's verification key.
opaque signature<1..2^16-1>; opaque signature<1..2^16-1>;
} }
1. The client upon receipt of this message should verify the 1. The client upon receipt of this message should verify the
"signature" using the "verification_key" from the configuration "signature" using the "verification_key" from the configuration
and return the "result". and return the "result".
6.2. Direct Redemption 6.2. Direct Redemption
Inputs: - "server_origin": The server origin to redeem a token for. - Inputs: - "context": The request context to use. - "server_origin":
"target": The target endpoint to send the token to. - The server origin to redeem a token for. - "target": The target
"additional_data": Additional data to bind to this redemption endpoint to send the token to. - "additional_data": Additional data
request. to bind to this redemption request.
1. When a client wants to redeem tokens for a server, it should 1. When a client wants to redeem tokens for a server, it should
first fetch a key commitment from the server via the process first fetch a key commitment from the server via the process
described in Section 4 and keep the result as "commitment". described in Section 4 and keep the result as "commitment".
2. The client should then look up the storage partition associated 2. The client should then look up the storage partition associated
with "server_origin" and fetch a "redemption_token" and with "server_origin" and fetch a "redemption_token" and
"public_key". "public_key".
3. The client should verify that the "public_key" is in the current 3. The client should verify that the "public_key" is in the current
skipping to change at line 411 skipping to change at page 10, line 4
the request to "target". The header will contain a message of the request to "target". The header will contain a message of
type "token-redemption" with a body of: type "token-redemption" with a body of:
struct { struct {
opaque server_id<1..2^16-1> = server_id; opaque server_id<1..2^16-1> = server_id;
uint16 ciphersuite = ciphersuite; uint16 ciphersuite = ciphersuite;
opaque public_key<1..2^16-1> = public_key; opaque public_key<1..2^16-1> = public_key;
RedemptionToken token<1..2^16-1> = redemption_token; RedemptionToken token<1..2^16-1> = redemption_token;
opaque additional_data<1..2^16-1> = additional_data; opaque additional_data<1..2^16-1> = additional_data;
} }
At this point, the "target" can perform a generic redemption as At this point, the "target" can perform a generic redemption as
described in Section 6.1 by forwarding the message included in the described in Section 6.1 by forwarding the message included in the
request to "target". request to "target".
6.3. Delegated Redemption 6.3. Delegated Redemption
Inputs: - "server_origin": The server origin to redeem a token for. - Inputs: - "context": The request context to use. - "server_origin":
"target": The target endpoint to send the token to. - The server origin to redeem a token for. - "target": The target
"additional_data": Additional data to bind to this redemption endpoint to send the token to. - "additional_data": Additional data
request. to bind to this redemption request.
1. When a client wants to redeem tokens for a server, it should 1. When a client wants to redeem tokens for a server, it should
first fetch a key commitment from the server via the process first fetch a key commitment from the server via the process
described in Section 4 and keep the result as "commitment". described in Section 4 and keep the result as "commitment".
2. The client should then look up the storage partition associated 2. The client should then look up the storage partition associated
with "server_origin" and fetch a "redemption_token" and with "server_origin" and fetch a "redemption_token" and
"public_key". "public_key".
3. The client should verify that the "public_key" is in the current 3. The client should verify that the "public_key" is in the current
skipping to change at line 473 skipping to change at page 11, line 24
"signed_redemption.info" based on the values of "target", "signed_redemption.info" based on the values of "target",
"timestamp", and "additional_data" and verify the signature of the "timestamp", and "additional_data" and verify the signature of the
redemption result by querying the current configuration of the redemption result by querying the current configuration of the
Privacy Pass server. The inclusion of "target" and "timestamp" Privacy Pass server. The inclusion of "target" and "timestamp"
proves that the server attested to the validity of the token in proves that the server attested to the validity of the token in
relation to this particular request. relation to this particular request.
7. Security Considerations 7. Security Considerations
Security considerations for Privacy Pass are discussed in Security considerations for Privacy Pass are discussed in
[draft-davidson-pp-architecture]. [draft-ietf-privacypass-architecture].
8. IANA Considerations 8. Privacy considerations
8.1. Well-Known URI General privacy considerations for Privacy Pass are discussed in
[draft-ietf-privacypass-architecture].
In order to implement this API with redemption contexts, a client
needs to maintain strong privacy boundaries between different
redemption contexts to avoid privacy leakage from redemptions across
them. Notably in the web/HTTP world, cross-site tracking and
fingerprinting will need to be considered and mitigated in order to
maintain these privacy boundaries.
9. IANA Considerations
9.1. Well-Known URI
This specification registers a new well-known URI. This specification registers a new well-known URI.
URI suffix: "privacy-pass" URI suffix: "privacy-pass"
Change controller: IETF. Change controller: IETF.
Specification document(s): this specification Specification document(s): this specification
9. Normative References 10. Normative References
[draft-davidson-pp-architecture]
Davidson, A., "Privacy Pass: Architectural Framework",
n.d., <https://tools.ietf.org/html/draft-davidson-pp-
architecture-00>.
[draft-davidson-pp-protocol]
Davidson, A., "Privacy Pass: The Protocol", n.d.,
<https://tools.ietf.org/html/draft-davidson-pp-protocol-
00>.
[draft-ietf-httpbis-header-structure-15] [draft-ietf-httpbis-header-structure-15]
Nottingham, M. and P-H. Kamp, "Structured Headers for Nottingham, M. and P-H. Kamp, "Structured Headers for
HTTP", n.d., <https://tools.ietf.org/html/draft-ietf- HTTP", n.d., <https://tools.ietf.org/html/draft-ietf-
httpbis-header-structure-15>. httpbis-header-structure-15>.
[draft-ietf-privacypass-architecture]
Davidson, A., "Privacy Pass: Architectural Framework",
n.d., <https://tools.ietf.org/html/draft-ietf-privacypass-
architecture-00>.
[draft-ietf-privacypass-protocol]
Davidson, A., "Privacy Pass: The Protocol", n.d.,
<https://tools.ietf.org/html/draft-ietf-privacypass-
protocol-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[verifiable-data-structures] [verifiable-data-structures]
"Verifiable Data Structures", n.d., "Verifiable Data Structures", n.d.,
<https://github.com/google/trillian/blob/master/docs/ <https://github.com/google/trillian/blob/master/docs/
papers/VerifiableDataStructures.pdf>. papers/VerifiableDataStructures.pdf>.
Author's Address Author's Address
Steven Valdez Steven Valdez
Google LLC Google LLC
 End of changes. 22 change blocks. 
60 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/