diff --git a/draft-ietf-privacypass-architecture.html b/draft-ietf-privacypass-architecture.html index b5d2ed56..f27e2c4e 100644 --- a/draft-ietf-privacypass-architecture.html +++ b/draft-ietf-privacypass-architecture.html @@ -656,7 +656,7 @@ } #toc nav li { line-height: 1.3em; - margin: 0.75em 0; + margin: 2px 0; padding-left: 1.2em; text-indent: -1.2em; } @@ -749,7 +749,7 @@ z-index: 2; top: 0; right: 0; - padding: 0; + padding: 1px 0 0 0; margin: 0; border-bottom: 1px solid #ccc; opacity: 0.6; @@ -873,16 +873,13 @@ border-top: none; padding-top: 0; } - figure, pre { + figure, pre, .vcard { page-break-inside: avoid; } - figure { - overflow: scroll; - } h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } - h2+*, h3+*, h4+*, h5+*, h6+* { + :is(h2, h3, h4, h5, h6)+*, dd { page-break-before: avoid; } pre { @@ -896,6 +893,9 @@ td { border-top: 1px solid #ddd; } + .toplink { + display: none; + } } @page :first { @@ -996,28 +996,6 @@ text-align: right; } -/* Give the table caption label the same styling as the figcaption */ - -@media print { - .toplink { - display: none; - } - - /* avoid overwriting the top border line with the ToC header */ - #toc { - padding-top: 1px; - } - - /* Avoid page breaks inside dl and author address entries */ - dd { - page-break-before: avoid; - } - .vcard { - page-break-inside: avoid; - } - -} - /* Dark mode. */ @media (prefers-color-scheme: dark) { :root { @@ -1058,7 +1036,7 @@ Davidson, et al. -Expires 24 March 2024 +Expires 28 March 2024 [Page] @@ -1071,12 +1049,12 @@
draft-ietf-privacypass-architecture-latest
Published:
- +
Intended Status:
Informational
Expires:
-
+
Authors:
@@ -1123,7 +1101,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 24 March 2024.

+ This Internet-Draft will expire on 28 March 2024.

Issuance context:
@@ -1584,7 +1562,7 @@

and Issuer, i.e., the information that is provided or otherwise available to Attester and Issuer during issuance that might be used to identify a Client. This context includes all information associated with issuance, such as the -timestamp of the event, any Client visible information (including the IP +timestamp of the event, any Client-visible information (including the IP address), and the Origin name (if revealed during issuance). This does not include the token challenge in its entirety, as that is kept secret from the Issuer during the issuance protocol.

@@ -1596,8 +1574,8 @@

the Client and Attester only, for the purposes of attesting the validity of the Client, that is provided or otherwise available during attestation that might be used to identify the Client. This context includes all information -associated with attestation, such as the timestamp of the event and any Client -visible information, including information needed for the attestation +associated with attestation, such as the timestamp of the event and any +Client-visible information, including information needed for the attestation procedure to complete.

@@ -1615,7 +1593,7 @@

necessary preconditions for context unlinkability, depends on the deployment model; see Section 4 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 +are deployment-specific. For example, in settings where Clients interact with Issuers through an Attester, Attesters and Issuers might use mutually authenticated TLS to authenticate one another. In settings where Clients do not communicate with Issuers through an Attester, the Attesters @@ -1623,7 +1601,8 @@

Clients explicitly trust Attesters to perform attestation correctly and in a 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 Section 4 for more about different +this information to non-colluding parties. Colluding parties are assumed to have +access to the same information; see Section 4 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 @@ -1812,7 +1791,7 @@

a challenge. The context in which an Attester vouches for a Client during issuance is referred to as the attestation context. This context includes all information associated with the issuance event, such as the timestamp of the -event and Client visible information, including the IP address or other +event and Client-visible information, including the IP address or other information specific to the type of attestation done.

Each issuance protocol may be different, e.g., in the number and types of participants, underlying cryptographic constructions used when issuing tokens, @@ -2163,13 +2142,12 @@

This section covers some expected deployment models and their corresponding security and privacy considerations. Each deployment model is described in terms of the trust relationships and communication patterns between Client, -Attester, Issuer, and Origin.

-

The discussion below assumes non-collusion between entities that have access to -the attestation, issuance, and redemption contexts, as collusion between such -entities would enable linking of these contexts and may lead to unlinkability -violations. Generally, this means that entities operated by separate parties do -not collude. Mechanisms for enforcing non-collusion are out of scope for this -architecture.

+Attester, Issuer, and Origin. Entities drawn within the same bounding box are +assumed to be operated by the same party and are therefore able to collude. +Collusion can enable linking of attestation, issuance, and redemption contexts. +Entities not drawn within the same bounding box are assumed to not +collude, meaning that entities operated by separate parties that do not collude. +Mechanisms for enforcing non-collusion are out of scope for this architecture.

diff --git a/draft-ietf-privacypass-architecture.txt b/draft-ietf-privacypass-architecture.txt index 344ea73f..e78fa609 100644 --- a/draft-ietf-privacypass-architecture.txt +++ b/draft-ietf-privacypass-architecture.txt @@ -5,10 +5,10 @@ Network Working Group A. Davidson Internet-Draft LIP Intended status: Informational J. Iyengar -Expires: 24 March 2024 Fastly +Expires: 28 March 2024 Fastly C. A. Wood Cloudflare - 21 September 2023 + 25 September 2023 The Privacy Pass Architecture @@ -39,7 +39,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 24 March 2024. + This Internet-Draft will expire on 28 March 2024. Copyright Notice @@ -213,7 +213,7 @@ Table of Contents 3. 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 + 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 @@ -267,7 +267,7 @@ Table of Contents Use cases for Privacy Pass are broad and depend greatly on the deployment model as discussed in Section 4. The initial motivating - use case for Privacy Pass [PrivacyPassCloudflare] was to help rate + use case for Privacy Pass [PrivacyPassCloudflare] was to help rate- limit malicious or otherwise abusive traffic from services such as Tor [DMS2004]. The generalized and evolved architecture described in this document also work for this use case. However, for added @@ -295,7 +295,7 @@ Table of Contents provided or otherwise available to the Origin during redemption that might be used to identify a Client and construct a token challenge. This context includes all information associated with - redemption, such as the timestamp of the event, Client visible + redemption, such as the timestamp of the event, Client-visible information (including the IP address), and the Origin name. Issuance context: The interactions and set of information shared @@ -303,7 +303,7 @@ Table of Contents that is provided or otherwise available to Attester and Issuer during issuance that might be used to identify a Client. This context includes all information associated with issuance, such as - the timestamp of the event, any Client visible information + the timestamp of the event, any Client-visible information (including the IP address), and the Origin name (if revealed during issuance). This does not include the token challenge in its entirety, as that is kept secret from the Issuer during the @@ -315,7 +315,7 @@ Table of Contents otherwise available during attestation that might be used to identify the Client. This context includes all information associated with attestation, such as the timestamp of the event - and any Client visible information, including information needed + and any Client-visible information, including information needed for the attestation procedure to complete. The privacy goals of Privacy Pass assume a threat model in which @@ -334,7 +334,7 @@ Table of Contents for more details. The mechanisms for establishing trust between each entity in this - arrangement are deployment specific. For example, in settings where + arrangement are deployment-specific. For example, in settings where Clients interact with Issuers through an Attester, Attesters and Issuers might use mutually authenticated TLS to authenticate one another. In settings where Clients do not communicate with Issuers @@ -345,9 +345,10 @@ Table of Contents and in a 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 Section 4 for more about different deployment - models and non-collusion assumptions. However, Clients assume - Issuers and Origins are malicious. + colluding parties. Colluding parties are assumed to have access to + the same information; see Section 4 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 unlinkability based on redemption, issuance, and @@ -515,7 +516,7 @@ Table of Contents a challenge. The context in which an Attester vouches for a Client during issuance is referred to as the attestation context. This context includes all information associated with the issuance event, - such as the timestamp of the event and Client visible information, + such as the timestamp of the event and Client-visible information, including the IP address or other information specific to the type of attestation done. @@ -866,14 +867,13 @@ Table of Contents corresponding security and privacy considerations. Each deployment model is described in terms of the trust relationships and communication patterns between Client, Attester, Issuer, and Origin. - - The discussion below assumes non-collusion between entities that have - access to the attestation, issuance, and redemption contexts, as - collusion between such entities would enable linking of these - contexts and may lead to unlinkability violations. Generally, this - means that entities operated by separate parties do not collude. - Mechanisms for enforcing non-collusion are out of scope for this - architecture. + Entities drawn within the same bounding box are assumed to be + operated by the same party and are therefore able to collude. + Collusion can enable linking of attestation, issuance, and redemption + contexts. Entities not drawn within the same bounding box are + assumed to not collude, meaning that entities operated by separate + parties that do not collude. Mechanisms for enforcing non-collusion + are out of scope for this architecture. 4.1. Shared Origin, Attester, Issuer diff --git a/draft-ietf-privacypass-auth-scheme.html b/draft-ietf-privacypass-auth-scheme.html index 13ce7cc6..ac2b4d07 100644 --- a/draft-ietf-privacypass-auth-scheme.html +++ b/draft-ietf-privacypass-auth-scheme.html @@ -657,7 +657,7 @@ } #toc nav li { line-height: 1.3em; - margin: 0.75em 0; + margin: 2px 0; padding-left: 1.2em; text-indent: -1.2em; } @@ -750,7 +750,7 @@ z-index: 2; top: 0; right: 0; - padding: 0; + padding: 1px 0 0 0; margin: 0; border-bottom: 1px solid #ccc; opacity: 0.6; @@ -874,16 +874,13 @@ border-top: none; padding-top: 0; } - figure, pre { + figure, pre, .vcard { page-break-inside: avoid; } - figure { - overflow: scroll; - } h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } - h2+*, h3+*, h4+*, h5+*, h6+* { + :is(h2, h3, h4, h5, h6)+*, dd { page-break-before: avoid; } pre { @@ -897,6 +894,9 @@ td { border-top: 1px solid #ddd; } + .toplink { + display: none; + } } @page :first { @@ -997,28 +997,6 @@ text-align: right; } -/* Give the table caption label the same styling as the figcaption */ - -@media print { - .toplink { - display: none; - } - - /* avoid overwriting the top border line with the ToC header */ - #toc { - padding-top: 1px; - } - - /* Avoid page breaks inside dl and author address entries */ - dd { - page-break-before: avoid; - } - .vcard { - page-break-inside: avoid; - } - -} - /* Dark mode. */ @media (prefers-color-scheme: dark) { :root { @@ -1059,7 +1037,7 @@ Pauly, et al. -Expires 24 March 2024 +Expires 28 March 2024 [Page] @@ -1072,12 +1050,12 @@
draft-ietf-privacypass-auth-scheme-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1123,7 +1101,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 24 March 2024.

+ This Internet-Draft will expire on 28 March 2024.