rfc9614v3.txt   rfc9614.txt 
skipping to change at line 104 skipping to change at line 104
between two endpoints. Some examples of this expansion include: between two endpoints. Some examples of this expansion include:
* A user accessing a service on a website might not consent to * A user accessing a service on a website might not consent to
reveal their location, but if that service is able to observe the reveal their location, but if that service is able to observe the
client's IP address, it can learn something about the user's client's IP address, it can learn something about the user's
location. This is problematic for privacy since the service can location. This is problematic for privacy since the service can
link user data to the user's location. link user data to the user's location.
* A user might want to be able to access content for which they are * A user might want to be able to access content for which they are
authorized, such as a news article; but the news service might authorized, such as a news article; but the news service might
track which users access which articles, even if the user doesn’t track which users access which articles, even if the user doesn't
want their activity to be tracked. This is problematic for want their activity to be tracked. This is problematic for
privacy since the service can link user activity to the user's privacy since the service can link user activity to the user's
account. account.
* A client device might need to upload metrics to an aggregation * A client device might need to upload metrics to an aggregation
service and in doing so allow the service to attribute the service and in doing so allow the service to attribute the
specific metrics contributions to that client device. This is specific metrics contributions to that client device. This is
problematic for privacy since the service can link client problematic for privacy since the service can link client
contributions to the specific client. contributions to the specific client.
skipping to change at line 601 skipping to change at line 601
Figure 6: Diagram of Oblivious HTTP Contexts Figure 6: Diagram of Oblivious HTTP Contexts
Oblivious DNS over HTTPS (ODoH) [ODOH] applies the same principle as Oblivious DNS over HTTPS (ODoH) [ODOH] applies the same principle as
Oblivious HTTP but operates on DNS messages only. As a precursor to Oblivious HTTP but operates on DNS messages only. As a precursor to
the more generalized Oblivious HTTP, it relies on the same HPKE the more generalized Oblivious HTTP, it relies on the same HPKE
cryptographic primitives and can be analyzed in the same way. cryptographic primitives and can be analyzed in the same way.
3.3. Privacy Pass 3.3. Privacy Pass
Privacy Pass is an architecture [PRIVACYPASS] and a set of protocols Privacy Pass is an architecture [RFC9576] and a set of protocols
being developed in the Privacy Pass Working Group that allows clients being developed in the Privacy Pass Working Group that allows clients
to present proof of verification in an anonymous and unlinkable to present proof of verification in an anonymous and unlinkable
fashion via tokens. These tokens were originally designed as a way fashion via tokens. These tokens were originally designed as a way
to prove that a client had solved a CAPTCHA, but they can be applied to prove that a client had solved a CAPTCHA, but they can be applied
to other types of user or device attestation checks as well. In to other types of user or device attestation checks as well. In
Privacy Pass, clients interact with an attester and issuer for the Privacy Pass, clients interact with an attester and issuer for the
purposes of issuing a token, and clients then interact with an origin purposes of issuing a token, and clients then interact with an origin
server to redeem said token. server to redeem said token.
In Privacy Pass, privacy partitioning is achieved with cryptographic In Privacy Pass, privacy partitioning is achieved with cryptographic
skipping to change at line 647 skipping to change at line 647
Figure 7: Diagram of Contexts in Privacy Pass Figure 7: Diagram of Contexts in Privacy Pass
Since the redemption context and issuance context are separate Since the redemption context and issuance context are separate
connections that involve separate entities, they can also be further connections that involve separate entities, they can also be further
decoupled by running those parts of the protocols at different times. decoupled by running those parts of the protocols at different times.
Clients can fetch tokens through the issuance context early and cache Clients can fetch tokens through the issuance context early and cache
the tokens for later use in redemption contexts. This can aid in the tokens for later use in redemption contexts. This can aid in
partitioning identifiers and data. partitioning identifiers and data.
[PRIVACYPASS] describes different deployment models for which [RFC9576] describes different deployment models for which entities
entities operate origins, attesters, and issuers; in some models, operate origins, attesters, and issuers; in some models, they are all
they are all separate entities, and in others they can be operated by separate entities, and in others they can be operated by the same
the same entity. The model impacts the effectiveness of entity. The model impacts the effectiveness of partitioning, and
partitioning, and some models (such as when all three are operated by some models (such as when all three are operated by the same entity)
the same entity) only provide effective partitioning when the timing only provide effective partitioning when the timing of connections on
of connections on the two contexts are not correlated and when the the two contexts are not correlated and when the client uses
client uses different identifiers (such as different IP addresses) on different identifiers (such as different IP addresses) on each
each context. context.
3.4. Privacy Preserving Measurement 3.4. Privacy Preserving Measurement
The Privacy Preserving Measurement (PPM) Working Group is chartered The Privacy Preserving Measurement (PPM) Working Group is chartered
to develop protocols and systems that help a data aggregation or to develop protocols and systems that help a data aggregation or
collection server (or multiple non-colluding servers) compute collection server (or multiple non-colluding servers) compute
aggregate values without learning the value of any one client's aggregate values without learning the value of any one client's
individual measurement. The Distributed Aggregation Protocol (DAP) individual measurement. The Distributed Aggregation Protocol (DAP)
is the primary working item of the group. is the primary working item of the group.
skipping to change at line 1107 skipping to change at line 1107
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230, Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022, DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>. <https://www.rfc-editor.org/info/rfc9230>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024, DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/info/rfc9458>. <https://www.rfc-editor.org/info/rfc9458>.
[PRIVACYPASS]
Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", Work in Progress, Internet-Draft,
draft-ietf-privacypass-architecture-16, 25 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-architecture-16>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RANDOM-MAC] [RANDOM-MAC]
Zuniga, JC., Bernardos, CJ., Ed., and A. Andersdotter, Zuniga, JC., Bernardos, CJ., Ed., and A. Andersdotter,
"Randomized and Changing MAC Address state of affairs", "Randomized and Changing MAC Address state of affairs",
Work in Progress, Internet-Draft, draft-ietf-madinas-mac- Work in Progress, Internet-Draft, draft-ietf-madinas-mac-
address-randomization-12, 28 February 2024, address-randomization-12, 28 February 2024,
skipping to change at line 1144 skipping to change at line 1137
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, DOI 10.17487/RFC8030, December 2016,
<https://www.rfc-editor.org/info/rfc8030>. <https://www.rfc-editor.org/info/rfc8030>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/info/rfc8981>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/info/rfc9576>.
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-18, 4 March 2024, draft-ietf-tls-esni-18, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-18>. esni-18>.
IAB Members at the Time of Approval IAB Members at the Time of Approval
Internet Architecture Board members at the time this document was Internet Architecture Board members at the time this document was
approved for publication were: approved for publication were:
 End of changes. 5 change blocks. 
18 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48.