Skip to content

Commit

Permalink
Script updating gh-pages from e669a80. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Sep 25, 2023
1 parent 7ea9a45 commit 9fe1cc3
Show file tree
Hide file tree
Showing 7 changed files with 78 additions and 144 deletions.
76 changes: 27 additions & 49 deletions draft-ietf-privacypass-architecture.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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;
}
Expand Down Expand Up @@ -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;
Expand Down Expand Up @@ -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 {
Expand All @@ -896,6 +893,9 @@
td {
border-top: 1px solid #ddd;
}
.toplink {
display: none;
}
}

@page :first {
Expand Down Expand Up @@ -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 {
Expand Down Expand Up @@ -1058,7 +1036,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Davidson, et al.</td>
<td class="center">Expires 24 March 2024</td>
<td class="center">Expires 28 March 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1071,12 +1049,12 @@
<dd class="internet-draft">draft-ietf-privacypass-architecture-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-09-21" class="published">21 September 2023</time>
<time datetime="2023-09-25" class="published">25 September 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-03-24">24 March 2024</time></dd>
<dd class="expires"><time datetime="2024-03-28">28 March 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1123,7 +1101,7 @@ <h2 id="name-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."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 24 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 28 March 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1433,7 +1411,7 @@ <h3 id="name-overview">
<li id="section-3.1-2.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 attestation process that is required for the
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
<a href="#attester" class="auto internal xref">Section 3.5.1</a> for more details.<a href="#section-3.1-2.3" class="pilcrow"></a>
Expand Down Expand Up @@ -1542,7 +1520,7 @@ <h3 id="name-use-cases">
</h3>
<p id="section-3.2-1">Use cases for Privacy Pass are broad and depend greatly on the deployment model
as discussed in <a href="#deployment" class="auto internal xref">Section 4</a>. The initial motivating use case for Privacy Pass
<span>[<a href="#PrivacyPassCloudflare" class="cite xref">PrivacyPassCloudflare</a>]</span> was to help rate limit malicious or otherwise abusive
<span>[<a href="#PrivacyPassCloudflare" class="cite xref">PrivacyPassCloudflare</a>]</span> was to help rate-limit malicious or otherwise abusive
traffic from services such as Tor <span>[<a href="#DMS2004" class="cite xref">DMS2004</a>]</span>. The generalized and evolved
architecture described in this document also work for this use case. However,
for added clarity, some more possible use cases are described below.<a href="#section-3.2-1" class="pilcrow"></a></p>
Expand Down Expand Up @@ -1575,7 +1553,7 @@ <h3 id="name-privacy-goals-and-threat-mo">
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 information (including the IP address), and the Origin name.<a href="#section-3.3-2.2.1" class="pilcrow"></a></p>
Client-visible information (including the IP address), and the Origin name.<a href="#section-3.3-2.2.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-3.3-2.3">Issuance context:</dt>
Expand All @@ -1584,7 +1562,7 @@ <h3 id="name-privacy-goals-and-threat-mo">
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.<a href="#section-3.3-2.4.1" class="pilcrow"></a></p>
Expand All @@ -1596,8 +1574,8 @@ <h3 id="name-privacy-goals-and-threat-mo">
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.<a href="#section-3.3-2.6.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
Expand All @@ -1615,15 +1593,16 @@ <h3 id="name-privacy-goals-and-threat-mo">
necessary preconditions for context unlinkability, depends on the deployment
model; see <a href="#deployment" class="auto internal xref">Section 4</a> for more details.<a href="#section-3.3-3" class="pilcrow"></a></p>
<p id="section-3.3-4">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
might convey this trust via a digital signature that Issuers can verify.<a href="#section-3.3-4" class="pilcrow"></a></p>
<p id="section-3.3-5">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 <a href="#deployment" class="auto internal xref">Section 4</a> for more about different
this information to non-colluding parties. Colluding parties are assumed to have
access to the same information; see <a href="#deployment" class="auto internal xref">Section 4</a> for more about different
deployment models and non-collusion assumptions. However, Clients assume Issuers and
Origins are malicious.<a href="#section-3.3-5" class="pilcrow"></a></p>
<p id="section-3.3-6">Given this threat model, the privacy goals of Privacy Pass are oriented around
Expand Down Expand Up @@ -1812,7 +1791,7 @@ <h3 id="name-issuance-protocol">
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.<a href="#section-3.5-3" class="pilcrow"></a></p>
<p id="section-3.5-4">Each issuance protocol may be different, e.g., in the number and types of
participants, underlying cryptographic constructions used when issuing tokens,
Expand Down Expand Up @@ -2163,13 +2142,12 @@ <h2 id="name-deployment-models">
<p id="section-4-2">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.<a href="#section-4-2" class="pilcrow"></a></p>
<p id="section-4-3">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.<a href="#section-4-3" class="pilcrow"></a></p>
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.<a href="#section-4-2" class="pilcrow"></a></p>
<div id="deploy-shared">
<section id="section-4.1">
<h3 id="name-shared-origin-attester-issu">
Expand Down
42 changes: 21 additions & 21 deletions draft-ietf-privacypass-architecture.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -295,15 +295,15 @@ 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
between the Client, Attester, 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
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
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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

Expand Down
Loading

0 comments on commit 9fe1cc3

Please sign in to comment.