rfc9614.original.xml   rfc9614.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -iab-privacy-partitioning-05" number="9614" category="info" submissionType="IAB"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft consensus="true" tocInclude="true" updates="" obsoletes="" sortRefs="true" symR
-iab-privacy-partitioning-05" category="info" submissionType="IAB" tocInclude="t efs="true" xml:lang="en" version="3">
rue" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.19.0 -->
<front> <front>
<title abbrev="Partitioning for Privacy">Partitioning as an Architecture for Privacy</title> <title abbrev="Partitioning for Privacy">Partitioning as an Architecture for Privacy</title>
<seriesInfo name="Internet-Draft" value="draft-iab-privacy-partitioning-05"/ <seriesInfo name="RFC" value="9614"/>
> <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
<author fullname="Mirja Kühlewind">
<organization>Ericsson Research</organization>
<address> <address>
<email>mirja.kuehlewind@ericsson.com</email> <email>mirja.kuehlewind@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Tommy Pauly"> <author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple</organization>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author fullname="Christopher A. Wood"> <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
<organization>Cloudflare</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="11"/>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 33?>
<t>This document describes the principle of privacy partitioning, which selectiv <date year="2024" month="July"/>
ely spreads data and communication across
multiple parties as a means to improve privacy by separating user identity from <keyword>MASQUE</keyword>
user data. <keyword>Privacy Pass</keyword>
This document describes emerging patterns in protocols to partition what data an <keyword>Oblivious HTTP</keyword>
d metadata is <keyword>Proxy</keyword>
revealed through protocol interactions, provides common terminology, and discuss
es how <abstract><t>This document describes the principle of privacy
to analyze such models.</t> partitioning, which selectively spreads data and communication across
multiple parties as a means to improve privacy by separating user identity
from user data. This document describes emerging patterns in protocols to
partition what data and metadata is revealed through protocol
interactions, provides common terminology, and discusses how to analyze
such models.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Internet Architecture Board Internet Engineering Task Force mailing list (ia
b@iab.org),
which is archived at <eref target=""/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/intarchboard/draft-obliviousness"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 41?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Protocols such as TLS and IPsec provide a secure (authenticated and enc <t>Protocols such as TLS and IPsec provide a secure (authenticated and
rypted) channel encrypted) channel between two endpoints over which endpoints transfer
between two endpoints over which endpoints transfer information. Encryption and information. Encryption and authentication of data in transit are
authentication necessary to protect information from being seen or modified by parties
of data in transit are necessary to protect information from being seen or modif other than the intended protocol participants. As such, this kind of
ied by parties security is necessary for ensuring that information transferred over
other than the intended protocol participants. As such, this kind of security is these channels remains private.</t>
necessary for ensuring that <t>However, a secure channel between two endpoints is insufficient for
information transferred over these channels remains private.</t> the privacy of the endpoints themselves. In recent years, privacy
<t>However, a secure channel between two endpoints is insufficient for the requirements have expanded beyond the need to protect data in transit
privacy of the endpoints between two endpoints. Some examples of this expansion include:</t>
themselves. In recent years, privacy requirements have expanded beyond the need
to protect data in transit
between two endpoints. Some examples of this expansion include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>A user accessing a service on a website might not consent to
<t>A user accessing a service on a website might not consent to reveal reveal their location, but if that service is able to observe the
their location, client's IP address, it can learn something about the user's
but if that service is able to observe the client's IP address, it can learn som location. This is problematic for privacy since the service can link
ething user data to the user's location.</li>
about the user's location. This is problematic for privacy since the service can <li>A user might want to be able to access content for which they are
link authorized, such as a news article; but the news service might track
user data to the user's location.</t> which users access which articles, even if the user doesn't want their
</li> activity to be tracked. This is problematic for privacy since the
<li> service can link user activity to the user's account.</li>
<t>A user might want to be able to access content for which they are a <li>A client device might need to upload metrics to an aggregation
uthorized, service and in doing so allow the service to attribute the specific
such as a news article, without needing to have which specific articles they metrics contributions to that client device. This is problematic for
read on their account being recorded. This is problematic for privacy since the privacy since the service can link client contributions to the
service specific client.</li>
can link user activity to the user's account.</t>
</li>
<li>
<t>A client device that needs to upload metrics to an aggregation serv
ice might want to be
able to contribute data to the system without having their specific contribution
s
attributed to them. This is problematic for privacy since the service can link c
lient
contributions to the specific client.</t>
</li>
</ul> </ul>
<t>The commonality in these examples is that clients want to interact with or use a service <t>The commonality in these examples is that clients want to interact with or use a service
without exposing too much user-specific or identifying information to that servi ce. In particular, without exposing too much user-specific or identifying information to that servi ce. In particular,
separating the user-specific identity information from user-specific data is nec essary for separating the user-specific identity information from user-specific data is nec essary for
privacy. Thus, in order to protect user privacy, it is important to keep identit y (who) and data privacy. Thus, in order to protect user privacy, it is important to keep identit y (who) and data
(what) separate.</t> (what) separate.</t>
<t>This document defines "privacy partitioning," sometimes also referred t o as the "decoupling principle" <t>This document defines "privacy partitioning," sometimes also referred t o as the "decoupling principle"
<xref target="DECOUPLING"/>, as the general technique used to separate the data <xref target="DECOUPLING"/>, as the general technique used to separate the data
and metadata visible to various parties in network communication, with the aim o f improving and metadata visible to various parties in network communication, with the aim o f improving
user privacy. Although privacy partitioning cannot guarantee there is no link be tween user-specific user privacy. Although privacy partitioning cannot guarantee there is no link be tween user-specific
identity and user-specific data, when applied properly it helps ensure that user privacy violations identity and user-specific data, when applied properly it helps ensure that user privacy violations
become more technically difficult to achieve over time.</t> become more technically difficult to achieve over time.</t>
<t>Several IETF working groups are working on protocols or systems that ad here to the principle <t>Several IETF working groups are working on protocols or systems that ad here to the principle
of privacy partitioning, including Oblivious HTTP Application Intermediation (OH AI), Multiplexed of privacy partitioning, including Oblivious HTTP Application Intermediation (OH AI), Multiplexed
Application Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy P reserving Measurement (PPM). This document summarizes Application Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy P reserving Measurement (PPM). This document summarizes
work in those groups and describes a framework for reasoning about the resulting privacy posture of different work in those groups and describes a framework for thinking about the resulting privacy posture of different
endpoints in practice.</t> endpoints in practice.</t>
<t>Privacy partitioning is particularly relevant as a tool for data minimi <t>Privacy partitioning is particularly relevant as a tool for data
zation, which is described minimization, which is described in <xref section="6.1"
in <xref section="6.1" sectionFormat="of" target="RFC6973"/>. <xref target="RFC6 sectionFormat="of" target="RFC6973"/>. <xref target="RFC6973"/> provides
973"/> provides guidance for privacy considerations in guidance for privacy considerations in Internet protocols, along with a
Internet protocols, along with a set of questions on how to evaluate the data mi set of questions on how to evaluate the data minimization of a protocol
nimization in <xref section="7.1" sectionFormat="of" target="RFC6973"/>. Protocols
of a protocol in <xref section="7.1" sectionFormat="of" target="RFC6973"/>. Prot that employ privacy partitioning ought to consider the questions in that
ocols that employ privacy partitioning section when evaluating their design, particularly with regard to how
ought to consider the questions in that section when evaluating their design, pa identifiers and data can be correlated by protocol participants and
rticularly observers in each context that has been partitioned. Privacy
with regard to how identifiers and data can be correlated by protocol participan partitioning can also be used as a way to separate identity providers
ts and from relying parties (see <xref section="6.1.4" sectionFormat="of"
observers in each context that has been partitioned. Privacy partitioning can al target="RFC6973"/>), as in the case of Privacy Pass (see <xref
so be target="privacypass"/>).</t>
used as a way to separate identity providers from relying parties <t>Privacy partitioning is not a panacea; applying it well requires
(see <xref section="6.1.4" sectionFormat="of" target="RFC6973"/>), as in the cas holistic analysis of the system in question to determine whether or not
e of Privacy Pass partitioning as a tool, and as implemented, offers meaningful privacy
(see Section <xref target="privacypass"/>).</t> improvements. See <xref target="limits"/> for more information.</t>
<t>Privacy partitioning is not a panacea; applying it well requires holist
ic analysis of the system
in question to determine whether or not partitioning as a tool, and as implement
ed, offers
meaningful privacy improvements. See <xref target="limits"/> for more informatio
n.</t>
</section> </section>
<section anchor="privacy-partitioning"> <section anchor="privacy-partitioning">
<name>Privacy Partitioning</name> <name>Privacy Partitioning</name>
<t>For the purposes of user privacy, this document focuses on user-specifi <t>For the purposes of user privacy, this document focuses on
c information. This user-specific information. This might include any identifying
might include any identifying information that is specific to a user, such as th information that is specific to a user, such as their email address or
eir email IP address, or any data about the user, such as their date of
address or IP address, or data about the user, such as their date of birth. Info birth. Informally, the goal of privacy partitioning is to ensure that
rmally, each party in a system beyond the user themselves only has access to
the goal of privacy partitioning is to ensure that each party in a system beyond one type of user-specific information.</t>
the user
themselves only have access to one type of user-specific information.</t>
<t>This is a simple application of the principle of least privilege, where in every party in <t>This is a simple application of the principle of least privilege, where in every party in
a system only has access to the minimum amount of information needed to fulfill their a system only has access to the minimum amount of information needed to fulfill their
function. Privacy partitioning advocates for this minimization by ensuring that protocols, function. Privacy partitioning advocates for this minimization by ensuring that protocols,
applications, and systems only reveal user-specific information to parties that need access applications, and systems only reveal user-specific information to parties that need access
to the information for their intended purpose.</t> to the information for their intended purpose.</t>
<t>Put simply, privacy partitioning aims to separate <em>who</em> someone is from <em>what</em> they do. In the <t>Put simply, privacy partitioning aims to separate <em>who</em> someone is from <em>what</em> they do. In the
rest of this section, we describe how privacy partitioning can be used to achiev e this goal.</t> rest of this section, we describe how privacy partitioning can be used to achiev e this goal.</t>
<section anchor="privacy-contexts"> <section anchor="privacy-contexts">
<name>Privacy Contexts</name> <name>Privacy Contexts</name>
<t>Each piece of user-specific information exists within some context, w here a context <t>Each piece of user-specific information exists within some context, w here a context
is abstractly defined as a set of data, metadata, and the entities that share ac cess is abstractly defined as a set of data, metadata, and the entities that share ac cess
to that information. In order to prevent the correlation of user-specific inform ation across to that information. In order to prevent the correlation of user-specific inform ation across
contexts, partitions need to ensure that any single entity (other than the clien t itself) contexts, partitions need to ensure that any single entity (other than the clien t itself)
does not participate in more than one context where the information is visible.< /t> does not participate in more than one context where the information is visible.< /t>
<t><xref target="RFC6973"/> discusses the importance of identifiers in r educing correlation as a way <t><xref target="RFC6973"/> discusses the importance of identifiers in r educing correlation as a way
of improving privacy:</t> of improving privacy:</t>
<blockquote> <blockquote>
<t>Correlation is the combination of various pieces of information rel <t>Correlation is the combination of various pieces of information
ated to an individual related to an individual or that obtain that characteristic when
or that obtain that characteristic when combined... Correlation is closely relat combined....</t>
ed to <t>Correlation is closely related to identification.
identification. Internet protocols can facilitate correlation by allowing indiv Internet protocols can facilitate correlation by allowing
iduals' individuals' activities to be tracked and combined over time....</t>
activities to be tracked and combined over time.</t> <t>Pseudonymity is strengthened when less personal data can be
<t>Pseudonymity is strengthened when less personal data can be linked linked to the pseudonym; when the same pseudonym is used less often
to the pseudonym; when and across fewer contexts; and when independently chosen pseudonyms
the same pseudonym is used less often and across fewer contexts; and when indepe are more frequently used for new actions (making them, from an
ndently observer's or attacker's perspective, unlinkable).</t>
chosen pseudonyms are more frequently used for new actions (making them, from an
observer's or
attacker's perspective, unlinkable).</t>
</blockquote> </blockquote>
<t>Context separation is foundational to privacy partitioning and reduci <t>Context separation is foundational to privacy partitioning and
ng correlation. reducing correlation. As an example, consider an unencrypted HTTP
As an example, consider an unencrypted HTTP session over TCP, wherein the contex session over TCP, wherein the context includes both the content of the
t includes both the transaction as well as any metadata from the transport and IP headers;
content of the transaction as well as any metadata from the transport and IP hea and the participants include the client, routers, other network
ders; and the middleboxes, intermediaries, and the server. Middleboxes or intermediar
participants include the client, routers, other network middleboxes, intermediar ies
ies, and server. might simply forward traffic or might terminate the traffic at any
Middlboxes or intermediaries might simply forward traffic, or might terminate th layer (such as terminating the TCP connection from the client and
e creating another TCP connection to the server). Regardless of how the
traffic at any layer (such as terminating the TCP connection from the client and middlebox interacts with the traffic, for the purposes of privacy
creating another partitioning, it is able to observe all of the data in the
TCP connection to the server). Regardless of how the middlebox interacts with th context.</t>
e traffic,
for the purposes of privacy partitioning, it is able to observe all of the data
in the context.</t>
<figure anchor="diagram-middlebox"> <figure anchor="diagram-middlebox">
<name>Diagram of a basic unencrypted client-to-server connection with middleboxes</name> <name>Diagram of a Basic Unencrypted Client-to-Server Connection with Middleboxes</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="560" viewBox="0 0 560 176" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="176" width="560" viewBox="0 0 560 176" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,160" fill="none" stroke="black"/> <path d="M 8,32 L 8,160" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 240,64 L 240,128" fill="none" stroke="black"/> <path d="M 240,64 L 240,128" fill="none" stroke="black"/>
<path d="M 336,64 L 336,128" fill="none" stroke="black"/> <path d="M 336,64 L 336,128" fill="none" stroke="black"/>
<path d="M 456,64 L 456,128" fill="none" stroke="black"/> <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
<path d="M 528,64 L 528,128" fill="none" stroke="black"/> <path d="M 528,64 L 528,128" fill="none" stroke="black"/>
<path d="M 552,32 L 552,160" fill="none" stroke="black"/> <path d="M 552,32 L 552,160" fill="none" stroke="black"/>
skipping to change at line 208 skipping to change at line 217
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | +------HTTP------+ +--------------+ | | | | +------HTTP------+ +--------------+ | |
| | Client | | Middlebox | | Server | | | | Client | | Middlebox | | Server | |
| | +------TCP-------+ +--------------+ | | | | +------TCP-------+ +--------------+ | |
| +--------+ flow +-----------+ +--------+ | | +--------+ flow +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Adding TLS encryption to the HTTP session is a simple partitioning te
chnique that splits the <t>Adding TLS encryption to the HTTP session is a simple partitioning
previous context into two separate contexts: the content of the transaction is n technique that splits the previous context into two separate contexts.
ow only visible The content of the transaction is now only visible to the client,
to the client, TLS-terminating intermediaries, and server; while the metadata in TLS-terminating intermediaries, and server, while the metadata in
transport and transport and IP headers remain in the original context. In this
IP headers remain in the original context. In this scenario, without any further scenario, without any further partitioning, the entities that
partitioning, participate in both contexts can allow the data in both contexts to be
the entities that participate in both contexts can allow the data in both contex correlated.</t>
ts to be correlated.</t>
<figure anchor="diagram-https"> <figure anchor="diagram-https">
<name>Diagram of how adding encryption splits the context into two</na me> <name>Diagram of How Adding Encryption Splits the Context into Two</na me>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,288" fill="none" stroke="black"/> <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 32,192 L 32,256" fill="none" stroke="black"/> <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 104,192 L 104,256" fill="none" stroke="black"/> <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
<path d="M 240,192 L 240,256" fill="none" stroke="black"/> <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
<path d="M 336,192 L 336,256" fill="none" stroke="black"/> <path d="M 336,192 L 336,256" fill="none" stroke="black"/>
<path d="M 456,64 L 456,128" fill="none" stroke="black"/> <path d="M 456,64 L 456,128" fill="none" stroke="black"/>
skipping to change at line 284 skipping to change at line 297
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | | | | | | | | | | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | | | | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow | | | | | | | | flow | | | | |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Another way to create a partition is to simply use separate connectio <t>Another way to create a partition is to simply use separate
ns. For example, to connections. For example, to split two separate HTTP requests from one
split two separate HTTP requests from one another, a client could issue the requ another, a client could issue the requests on separate TCP
ests on connections, each on a different network and at different times, and
separate TCP connections, each on a different network, and at different times; a avoid including obvious identifiers like HTTP cookies across the
nd avoid requests.</t>
including obvious identifiers like HTTP cookies across the requests.</t>
<figure anchor="diagram-dualconnect"> <figure anchor="diagram-dualconnect">
<name>Diagram of making separate connections to generate separate cont exts</name> <name>Diagram of Making Separate Connections to Generate Separate Cont exts</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,288" fill="none" stroke="black"/> <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 32,192 L 32,256" fill="none" stroke="black"/> <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 104,192 L 104,256" fill="none" stroke="black"/> <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
<path d="M 240,64 L 240,128" fill="none" stroke="black"/> <path d="M 240,64 L 240,128" fill="none" stroke="black"/>
<path d="M 240,192 L 240,256" fill="none" stroke="black"/> <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
<path d="M 336,64 L 336,128" fill="none" stroke="black"/> <path d="M 336,64 L 336,128" fill="none" stroke="black"/>
skipping to change at line 379 skipping to change at line 394
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Using separate connections to create separate contexts can reduce or eliminate <t>Using separate connections to create separate contexts can reduce or eliminate
the ability of specific parties to correlate activity across contexts. However, the ability of specific parties to correlate activity across contexts. However,
any identifier at any layer that is common across different contexts can be any identifier at any layer that is common across different contexts can be
used as a way to correlate activity. Beyond IP addresses, many other factors used as a way to correlate activity. Beyond IP addresses, many other factors
can be used together to create a fingerprint of a specific device (such as can be used together to create a fingerprint of a specific device (such as
MAC addresses, device properties, software properties and behavior, application state, etc).</t> Media Access Control (MAC) addresses, device properties, software properties and behavior, application state, etc.).</t>
</section> </section>
<section anchor="context-separation"> <section anchor="context-separation">
<name>Context Separation</name> <name>Context Separation</name>
<t>In order to define and analyze how various partitioning techniques wo rk, the boundaries of what is <t>In order to define and analyze how various partitioning techniques wo rk, the boundaries of what is
being partitioned need to be established. This is the role of context separation . In particular, being partitioned need to be established. This is the role of context separation . In particular,
in order to prevent the correlation of user-specific information across contexts , partitions need in order to prevent the correlation of user-specific information across contexts , partitions need
to ensure that any single entity (other than the client itself) does not partici pate in contexts to ensure that any single entity (other than the client itself) does not partici pate in contexts
where both identifiers are visible.</t> where both identifiers are visible.</t>
<t>Context separation can be achieved in different ways, for example, ov er time, across network paths, based <t>Context separation can be achieved in different ways, for example, ov er time, across network paths, based
on (en)coding, etc. The privacy-oriented protocols described in this document ge nerally involve on (en)coding, etc. The privacy-oriented protocols described in this document ge nerally involve
more complex partitioning, but the techniques to partition communication context s still employ the more complex partitioning, but the techniques to partition communication context s still employ the
same techniques:</t> same techniques:</t>
<ol spacing="normal" type="1"><li> <ul spacing="normal">
<t>Cryptographic protection, such as the use of encryption to specif <li>Cryptographic protection, such as the use of encryption to
ic parties, allows specific parties, allows partitioning of contexts between different
partitioning of contexts between different parties (those with the ability to re parties (those with the ability to remove cryptographic protections,
move and those without).</li>
cryptographic protections, and those without).</t> <li>Connection separation across time or space to allow
</li> partitioning of contexts for different application transactions over
<li> the network.</li>
<t>Connection separation across time or space to allow partitioning </ul>
of contexts for different
application transactions over the network.</t>
</li>
</ol>
<t>These techniques are frequently used in conjunction for context separ ation. For example, <t>These techniques are frequently used in conjunction for context separ ation. For example,
encrypting an HTTP exchange using TLS between client and TLS-terminating server might prevent encrypting an HTTP exchange using TLS between the client and TLS-terminating ser ver might prevent
a network middlebox that sees a client IP address from seeing the user account i dentifier, a network middlebox that sees a client IP address from seeing the user account i dentifier,
but it doesn't prevent the TLS-terminating server from observing both identifier s and correlating but it doesn't prevent the TLS-terminating server from observing both identifier s and correlating
them. As such, preventing correlation requires separating contexts, such as by u sing proxying to them. As such, preventing correlation requires separating contexts, such as by u sing proxying to
conceal a client's IP address that would otherwise be used as an identifier.</t> conceal a client's IP address that would otherwise be used as an identifier.</t>
</section> </section>
<section anchor="approaches-to-partitioning"> <section anchor="approaches-to-partitioning">
<name>Approaches to Partitioning</name> <name>Approaches to Partitioning</name>
<t>While all of the partitioning protocols described in this document cr <t>While all of the partitioning protocols described in this document
eate create separate contexts using cryptographic protection and/or
separate contexts using cryptographic protection and/or connection separation, e connection separation, each one has a unique approach that results in
ach one has a different sets of contexts. Since many of these protocols are new, it
unique approach that results in different sets of contexts. Since many of is yet to be seen how each approach will be used at scale across the
these protocols are new, it is yet to be seen how each approach will be Internet and what new models will emerge in the future.</t>
used at scale across the Internet, and what new models will emerge in the <t>There are multiple factors that lead to a diversity in approaches
future.</t> to partitioning, including:</t>
<t>There are multiple factors that lead to a diversity in approaches to
partitioning, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Adding privacy partitioning to existing protocol ecosystems
<t>Adding privacy partitioning to existing protocol ecosystems place places requirements and constraints on how contexts are
s constructed. CONNECT-style proxying is intended to work with servers
requirements and constraints on how contexts are constructed. CONNECT-style that are unaware of privacy contexts, requiring more intermediaries
proxying is intended to work with servers that are unaware of privacy contexts, to provide strong separation guarantees. On the other hand,
requiring more intermediaries to provide strong separation guarantees. Oblivious HTTP assumes servers that cooperate with context
Oblivious HTTP, on the other hand, assumes servers that cooperate with context separation and, thus, reduces the overall number of elements in the
separation, and thus reduces the overall number of elements in the solution.</t> solution.</li>
</li> <li>Whether or not information exchange needs to happen
<li> bidirectionally in an interactive fashion determines how contexts
<t>Whether or not information exchange needs to happen bidirectional can be separated. Some use cases, like metrics collection for PPM,
ly in an can occur whereby information only flows from clients to servers and
interactive fashion determines how contexts can be separated. Some use cases, can function even when clients are no longer connected. Privacy
like metrics collection for PPM, can occur with information flowing only from Pass is an example of a case that can be either interactive or not,
clients to servers, and can function even when clients are no longer connected. depending on whether tokens can be cached and reused. CONNECT-style
Privacy Pass is an example of a case that can be either interactive or not, proxying and Oblivious HTTP often require bidirectional and
depending on whether tokens can be cached and reused. CONNECT-style proxying and interactive communication.</li>
Oblivious HTTP often requires bidirectional and interactive communication.</t> <li>The degree to which contexts need to be partitioned depends in
</li> part on the client's threat models and level of trust in various
<li> protocol participants. For example, in Oblivious HTTP, clients allow
<t>The degree to which contexts need to be partitioned depends in pa relays to learn that clients are accessing a particular
rt application-specific gateway. If clients do not trust relays with
on the client's threat models and level of trust in various protocol participant this information, they can instead use a multi-hop CONNECT-style
s. For example, proxy approach wherein no single party learns whether specific
in Oblivious HTTP, clients allow relays to learn that clients are accessing a pa clients are accessing a specific application. This is the default
rticular trust model for systems like Tor, where multiple hops are used to
application-specific gateway. If clients do not trust relays with this informati drive down the probability of privacy violations due to collusion or
on, they can related attacks.</li>
instead use a multi-hop CONNECT-style proxy approach wherein no single party lea
rns
whether specific clients are accessing a specific application. This is the defau
lt trust model
for systems like Tor, where multiple hops are used to drive down the probability
of privacy
violations due to collusion or related attacks.</t>
</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="a-survey-of-protocols-using-partitioning"> <section anchor="a-survey-of-protocols-using-partitioning">
<name>A Survey of Protocols using Partitioning</name> <name>A Survey of Protocols Using Partitioning</name>
<t>The following section discusses current on-going work in the IETF <t>The following section discusses current on-going work in the IETF
that is applying privacy partitioning.</t> that is applying privacy partitioning.</t>
<section anchor="masque"> <section anchor="masque">
<name>CONNECT Proxying and MASQUE</name> <name>CONNECT Proxying and MASQUE</name>
<t>HTTP forward proxies, when using encryption on the connection between <t>When using encryption on the connection between the client and the
the client and the proxy, HTTP forward proxies provide privacy partitioning by separating
proxy, provide privacy partitioning by separating a connection into multiple seg a connection into multiple segments. When connections to targets via
ments. the proxy themselves are encrypted, the proxy cannot see the
When connections to targets via the proxy themselves are encrypted, end-to-end content. HTTP has historically supported forward proxying
the proxy cannot see the end-to-end content. HTTP has historically supported for for TCP-like streams via the CONNECT method. More recently, the
ward proxying Multiplexed Application Substrate over QUIC Encryption (MASQUE)
for TCP-like streams via the CONNECT method. More recently, the Multiplexed Appl Working Group has developed protocols to similarly proxy UDP <xref
ication target="RFC9297"/> and IP packets <xref target="RFC9484"/> based on
Substrate over QUIC Encryption (MASQUE) working group has developed tunneling.</t>
protocols to similarly proxy UDP <xref target="CONNECT-UDP"/> and IP packets <t>In a single-proxy setup, there is a tunnel connection between the
<xref target="CONNECT-IP"/> based on tunneling.</t> client and proxy and an end-to-end connection that is tunneled between
<t>In a single-proxy setup, there is a tunnel connection between the cli the client and target. This setup, as shown in <xref
ent and proxy and target="diagram-1hop"/>, partitions communication into:</t>
an end-to-end connection that is tunnelled between the client and target. This s
etup,
as shown in the figure below, partitions communication into:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>a Client-to-Target encrypted context, which contains the
<t>a Client-to-Target encrypted context, which contains the end-to-e end-to-end content within the TLS session to the target, such as
nd content HTTP content;</li>
within the TLS session to the target, such as HTTP content;</t> <li>a Client-to-Target proxied context, which is the end-to-end data
</li> exchanged with the target that is also visible to the proxy, such as a
<li> TLS
<t>a Client-to-Target proxied context, which is the end-to-end data session;</li>
to the target that is <li>a Client-to-Proxy context, which contains the transport metadata
also visible to the proxy, such as a TLS session;</t> between the client and the target, and the request to the proxy to
</li> open a connection to the target; and </li>
<li> <li>a Proxy-to-Target context, which for TCP and UDP proxying
<t>a Client-to-Proxy context, which contains the transport metadata contains any packet header information that is added or modified by
between the client the proxy, e.g., the IP and TCP/UDP headers.</li>
and the target, and the request to the proxy to open a connection to the target;
</t>
</li>
<li>
<t>and a Proxy-to-Target context, which for TCP and UDP proxying
contains any packet header information that is added or modified by the proxy,
e.g., the IP and TCP/UDP headers.</t>
</li>
</ul> </ul>
<figure anchor="diagram-1hop"> <figure anchor="diagram-1hop">
<name>Diagram of one-hop proxy contexts</name> <name>Diagram of One-Hop Proxy Contexts</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,544" fill="none" stroke="black"/> <path d="M 8,32 L 8,544" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 32,192 L 32,256" fill="none" stroke="black"/> <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
<path d="M 32,320 L 32,384" fill="none" stroke="black"/> <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 104,192 L 104,256" fill="none" stroke="black"/> <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
<path d="M 104,320 L 104,384" fill="none" stroke="black"/> <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
<path d="M 240,192 L 240,256" fill="none" stroke="black"/> <path d="M 240,192 L 240,256" fill="none" stroke="black"/>
skipping to change at line 611 skipping to change at line 625
| +-----------+ +--------+ | | +-----------+ +--------+ |
| | | | | | | | | | | |
| | Proxy +--Transport---+ Target | | | | Proxy +--Transport---+ Target | |
| | | flow | | | | | | flow | | |
| +-----------+ +--------+ | | +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Using two (or more) proxies provides better privacy partitioning. In <t>Using two (or more) proxies provides better privacy
particular, with two proxies, partitioning. In particular, with two proxies, each proxy sees the
each proxy sees the Client metadata, but not the Target; the Target, but not the Client metadata but not the Target, the Target but not the Client
Client metadata, or neither.</t>
metadata; or neither.</t> <t>In addition to the contexts described above for the single proxy
<t>In addition to the contexts described above for the single proxy case case, the two-hop proxy case shown in <xref target="diagram-2hop"/>
, changes the contexts in several ways:</t>
the two-hop proxy case shown in the figure below changes the contexts
in several ways:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>the Client-to-Target proxied context only includes the second
<t>the Client-to-Target proxied context only includes the second pro proxy (referred to here as "Proxy B");</li>
xy <li>a new Client-to-Proxy B context is added, which is the TLS
(referred to here as "Proxy B");</t> session from the client to Proxy B that is also visible to the first
</li> proxy (referred to here as "Proxy A");</li>
<li> <li>the contexts that see transport data only (TCP or UDP over IP)
<t>a new Client-to-Proxy B context is added, which is the TLS sessio are separated out into three separate contexts, a Client-to-Proxy A
n context, a Proxy A-to-Proxy B context, and a Proxy B-to-Target
from the client to Proxy B that is also visible to the first proxy context.</li>
(referred to here as "Proxy A");</t> </ul>
</li>
<li>
<t>the contexts that see transport data only (TCP or UDP over IP)
are separated out into three separate contexts, a Client-to-Proxy A
context, a Proxy A-to-Proxy B context, and a Proxy B-to-Target context.</t>
</li>
</ul>
<figure anchor="diagram-2hop"> <figure anchor="diagram-2hop">
<name>Diagram of two-hop proxy contexts</name> <name>Diagram of Two-Hop Proxy Contexts</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="816" width="560" viewBox="0 0 560 816" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="816" width="560" viewBox="0 0 560 816" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,800" fill="none" stroke="black"/> <path d="M 8,32 L 8,800" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 32,192 L 32,256" fill="none" stroke="black"/> <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
<path d="M 32,320 L 32,384" fill="none" stroke="black"/> <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
<path d="M 32,448 L 32,512" fill="none" stroke="black"/> <path d="M 32,448 L 32,512" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 104,192 L 104,256" fill="none" stroke="black"/> <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
<path d="M 104,320 L 104,384" fill="none" stroke="black"/> <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
skipping to change at line 814 skipping to change at line 824
| +-------+ +--------+ | | +-------+ +--------+ |
| | | | | | | | | | | |
| | Proxy +-------+ Target | | | | Proxy +-------+ Target | |
| | B | | | | | | B | | | |
| +-------+ +--------+ | | +-------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Forward proxying, such as the protocols developed in MASQUE, uses bot
h encryption (via TLS) and <t>Forward proxying, such as the modes of proxying in the protocols
separation of connections (via proxy hops that see only the next hop) to achieve developed in MASQUE, uses both encryption (via TLS) and separation of
privacy partitioning.</t> connections (via proxy hops that see only the next hop) to achieve
privacy partitioning.</t>
</section> </section>
<section anchor="oblivious-http-and-dns"> <section anchor="oblivious-http-and-dns">
<name>Oblivious HTTP and DNS</name> <name>Oblivious HTTP and DNS</name>
<t>Oblivious HTTP <xref target="OHTTP"/>, developed in the Oblivious HTT <t>Oblivious HTTP <xref target="RFC9458"/>, developed in the Oblivious
P Application HTTP Application Intermediation (OHAI) Working Group, adds per-message
Intermediation (OHAI) working group, adds per-message encryption to HTTP exchanges through a relay system. Clients send
encryption to HTTP exchanges through a relay system. Clients send requests throu requests through an Oblivious Relay, which cannot read message
gh an Oblivious Relay, contents, to an Oblivious Gateway, which can decrypt the messages but
which cannot read message contents, to an Oblivious Gateway, which can decrypt t cannot communicate directly with the client or observe client metadata
he messages but like an IP address. Oblivious HTTP relies on Hybrid Public Key
cannot communicate directly with the client or observe client metadata like IP a Encryption <xref target="RFC9180"/> to perform encryption.</t>
ddress. <t>Oblivious HTTP uses both encryption and separation of connections
Oblivious HTTP relies on Hybrid Public Key Encryption <xref target="HPKE"/> to p to achieve privacy partitioning.</t>
erform encryption.</t>
<t>Oblivious HTTP uses both encryption and separation of connections to
achieve privacy partitioning.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>End-to-end messages are encrypted between the Client and
<t>End-to-end messages are encrypted between the Client and Gateway. Gateway. The content of these inner messages are visible to the
The Client, Gateway, and Target. This is the Client-to-Target
content of these inner messages are visible to the Client, Gateway, and context.</li>
Target. This is the Client-to-Target context.</t> <li>The encrypted messages exchanged between the Client and Gateway
</li> are visible to the Relay, but the Relay cannot decrypt the messages.
<li> This is the Client-to-Gateway context.</li>
<t>The encrypted messages exchanged between the Client and Gateway <li>The transport (such as TCP and TLS) connections between the
are visible to the Relay, but the Relay cannot decrypt the messages. Client, Relay, and Gateway form two separate contexts: a
This is the Client-to-Gateway context.</t> Client-to-Relay context and a Relay-to-Gateway context. It is
</li> important to note that the Relay-to-Gateway connection can be a
<li> single connection, even if the Relay has many separate Clients. This
<t>The transport (such as TCP and TLS) connections between the Clien provides better anonymity by making the pseudonym presented by the
t, Relay to be shared across many Clients.</li>
Relay, and Gateway form two separate contexts: a Client-to-Relay
context and a Relay-to-Gateway context. It is important
to note that the Relay-to-Gateway connection can be a single connection,
even if the Relay has many separate Clients. This provides better anonymity
by making the pseudonym presented by the Relay to be shared across many Clients.
</t>
</li>
</ul> </ul>
<figure anchor="diagram-ohttp"> <figure anchor="diagram-ohttp">
<name>Diagram of Oblivious HTTP contexts</name> <name>Diagram of Oblivious HTTP Contexts</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="560" width="560" viewBox="0 0 560 560" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,544" fill="none" stroke="black"/> <path d="M 8,32 L 8,544" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 32,192 L 32,256" fill="none" stroke="black"/> <path d="M 32,192 L 32,256" fill="none" stroke="black"/>
<path d="M 32,320 L 32,384" fill="none" stroke="black"/> <path d="M 32,320 L 32,384" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 104,192 L 104,256" fill="none" stroke="black"/> <path d="M 104,192 L 104,256" fill="none" stroke="black"/>
<path d="M 104,320 L 104,384" fill="none" stroke="black"/> <path d="M 104,320 L 104,384" fill="none" stroke="black"/>
<path d="M 184,192 L 184,256" fill="none" stroke="black"/> <path d="M 184,192 L 184,256" fill="none" stroke="black"/>
skipping to change at line 962 skipping to change at line 974
| +-------+ +---------+ | | +-------+ +---------+ |
| | | | | | | | | | | |
| + Relay +---------+ Gateway | | | + Relay +---------+ Gateway | |
| | | | | | | | | | | |
| +-------+ +---------+ | | +-------+ +---------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Oblivious DNS over HTTPS <xref target="ODOH"/> applies the same princ <t>Oblivious DNS over HTTPS (ODoH) <xref target="RFC9230"/> applies the
iple as Oblivious HTTP, but operates on same
DNS messages only. As a precursor to the more generalized Oblivious HTTP, it rel principle as Oblivious HTTP but operates on DNS messages only. As a
ies on the same precursor to the more generalized Oblivious HTTP, it relies on the
HPKE cryptographic primitives, and can be analyzed in the same way.</t> same HPKE cryptographic primitives and can be analyzed in the same
way.</t>
</section> </section>
<section anchor="privacypass"> <section anchor="privacypass">
<name>Privacy Pass</name> <name>Privacy Pass</name>
<t>Privacy Pass is an architecture <xref target="PRIVACYPASS"/> and a se <t>Privacy Pass is an architecture <xref
t of protocols target="RFC9576"/> and a set of protocols
being developed in the Privacy Pass working group that allows clients to present being developed in the Privacy Pass Working Group that allows clients
proof of verification in to present proof of verification in an anonymous and unlinkable
an anonymous and unlinkable fashion, via tokens. These tokens originally were de fashion via tokens. These tokens were originally designed as a way to
signed as a way to prove prove that a client had solved a CAPTCHA, but they can be applied to oth
that a client had solved a CAPTCHA, but can be applied to other types of user or er
device attestation checks types of user or device attestation checks as well. In Privacy Pass,
as well. In Privacy Pass, clients interact with an attester and issuer for the p clients interact with an attester and issuer for the purposes of
urposes of issuing a token, issuing a token, and clients then interact with an origin server to
and clients then interact with an origin server to redeem said token.</t> redeem said token.</t>
<t>In Privacy Pass, privacy partitioning is achieved with cryptographic protection (in the form of blind <t>In Privacy Pass, privacy partitioning is achieved with cryptographic protection (in the form of blind
signature protocols or similar) and separation of connections across two context s: signature protocols or similar) and separation of connections across two context s:
a "redemption context" between clients and origins (servers that request and rec eive tokens), and an a "redemption context" between clients and origins (servers that request and rec eive tokens), and an
"issuance context" between clients, attestation servers, and token issuance serv ers. The cryptographic "issuance context" between clients, attestation servers, and token issuance serv ers. The cryptographic
protection ensures that information revealed during the issuance context is sepa rated from information protection ensures that information revealed during the issuance context is sepa rated from information
revealed during the redemption context.</t> revealed during the redemption context.</t>
<figure anchor="diagram-privacypass"> <figure anchor="diagram-privacypass">
<name>Diagram of contexts in Privacy Pass</name> <name>Diagram of Contexts in Privacy Pass</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="304" width="560" viewBox="0 0 560 304" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,288" fill="none" stroke="black"/> <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
<path d="M 32,64 L 32,128" fill="none" stroke="black"/> <path d="M 32,64 L 32,128" fill="none" stroke="black"/>
<path d="M 104,64 L 104,128" fill="none" stroke="black"/> <path d="M 104,64 L 104,128" fill="none" stroke="black"/>
<path d="M 184,64 L 184,128" fill="none" stroke="black"/> <path d="M 184,64 L 184,128" fill="none" stroke="black"/>
<path d="M 184,192 L 184,256" fill="none" stroke="black"/> <path d="M 184,192 L 184,256" fill="none" stroke="black"/>
<path d="M 256,64 L 256,128" fill="none" stroke="black"/> <path d="M 256,64 L 256,128" fill="none" stroke="black"/>
<path d="M 256,192 L 256,256" fill="none" stroke="black"/> <path d="M 256,192 L 256,256" fill="none" stroke="black"/>
<path d="M 312,192 L 312,256" fill="none" stroke="black"/> <path d="M 312,192 L 312,256" fill="none" stroke="black"/>
skipping to change at line 1046 skipping to change at line 1064
| +--------+ +----------+ +--------+ | | +--------+ +----------+ +--------+ |
| | | | | | | | | | | | | | | |
| | Client +------+ Attester +------+ Issuer | | | | Client +------+ Attester +------+ Issuer | |
| | | | | | | | | | | | | | | |
| +--------+ +----------+ +--------+ | | +--------+ +----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Since the redemption context and issuance context are separate connec
tions <t>Since the redemption context and issuance context are separate
that involve separate entities, they can also be further decoupled by connections that involve separate entities, they can also be further
running those parts of the protocols at different times. Clients can decoupled by running those parts of the protocols at different times.
fetch tokens through the issuance context early, and cache the tokens Clients can fetch tokens through the issuance context early and cache
to later use in redemption contexts. This can aid in partitioning identifiers the tokens for later use in redemption contexts. This can aid in
and data.</t> partitioning identifiers and data.</t>
<t><xref target="PRIVACYPASS"/> describes different deployment models fo <t><xref target="RFC9576"/> describes
r which entities operate different deployment models for which entities operate origins,
origins, attesters, and issuers; in some models, they are all separate attesters, and issuers; in some models, they are all separate
entities, but in others, they can be operated by the same entity. The entities, and in others they can be operated by the same entity. The
model impacts the effectiveness of partitioning, and some models model impacts the effectiveness of partitioning, and some models (such
(such as when all three are operated by the same entity) only provide as when all three are operated by the same entity) only provide
effective partitioning when the timing of connections on the two effective partitioning when the timing of connections on the two
contexts are not correlated, and when the client uses different contexts are not correlated and when the client uses different
identifiers (such as different IP addresses) on each context.</t> identifiers (such as different IP addresses) on each context.</t>
</section> </section>
<section anchor="privacy-preserving-measurement"> <section anchor="privacy-preserving-measurement">
<name>Privacy Preserving Measurement</name> <name>Privacy Preserving Measurement</name>
<t>The Privacy Preserving Measurement (PPM) working group is chartered t <t>The Privacy Preserving Measurement (PPM) Working Group is chartered
o develop protocols and systems to develop protocols and systems that help a data aggregation or
that help a data aggregation or collection server (or multiple, non-colluding se collection server (or multiple non-colluding servers) compute
rvers) compute aggregate aggregate values without learning the value of any one client's
values without learning the value of any one client's individual measurement. Di individual measurement. The Distributed Aggregation Protocol (DAP) is th
stributed Aggregation e
Protocol (DAP) is the primary working item of the group.</t> primary working item of the group.</t>
<t>At a high level, DAP uses a combination of cryptographic protection ( <t>At a high level, DAP uses a combination of cryptographic protection
in the form of secret sharing amongst (in the form of secret sharing amongst non-colluding servers) to
non-colluding servers) to establish two contexts: an "upload context" between cl establish two contexts:</t>
ients and non-colluding <ul spacing="normal">
aggregation servers (in which the servers are separated into "Helper" and "Leade
r" roles) wherein aggregation <li>an "upload context" between clients and non-colluding
servers possibly learn client identity but nothing about their individual measur aggregation servers (in which the servers are separated into
ement reports, and "Helper" and "Leader" roles) wherein aggregation servers possibly
a "collect context" wherein a collector learns aggregate measurement results and learn client identity but nothing about their individual measurement
nothing reports; and</li>
about individual client data.</t> <li>a "collect context" wherein a collector learns
aggregate measurement results and nothing about individual client
data.</li>
</ul>
<figure anchor="pa-topology"> <figure anchor="pa-topology">
<name>Diagram of contexts in DAP</name> <name>Diagram of Contexts in DAP</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="224" width="488" viewBox="0 0 488 224" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="224" width="488" viewBox="0 0 488 224" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,208" fill="none" stroke="black"/> <path d="M 8,32 L 8,208" fill="none" stroke="black"/>
<path d="M 24,96 L 24,160" fill="none" stroke="black"/> <path d="M 24,96 L 24,160" fill="none" stroke="black"/>
<path d="M 96,96 L 96,160" fill="none" stroke="black"/> <path d="M 96,96 L 96,160" fill="none" stroke="black"/>
<path d="M 128,80 L 128,112" fill="none" stroke="black"/> <path d="M 128,80 L 128,112" fill="none" stroke="black"/>
<path d="M 128,144 L 128,176" fill="none" stroke="black"/> <path d="M 128,144 L 128,176" fill="none" stroke="black"/>
<path d="M 184,64 L 184,96" fill="none" stroke="black"/> <path d="M 184,64 L 184,96" fill="none" stroke="black"/>
<path d="M 184,160 L 184,192" fill="none" stroke="black"/> <path d="M 184,160 L 184,192" fill="none" stroke="black"/>
<path d="M 240,104 L 240,152" fill="none" stroke="black"/> <path d="M 240,104 L 240,152" fill="none" stroke="black"/>
skipping to change at line 1145 skipping to change at line 1176
| +----->| Leader |<-----------+ | | +----->| Leader |<-----------+ |
| +------------+ | | | +------------+ | |
+-------------------------------------+--------------------+ +-------------------------------------+--------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="applying-privacy-partitioning"> <section anchor="applying-privacy-partitioning">
<name>Applying Privacy Partitioning</name> <name>Applying Privacy Partitioning</name>
<t>Applying privacy partitioning to an existing or new system or protocol <t>Applying privacy partitioning to an existing or new system or
requires the following steps:</t> protocol requires the following steps:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>Identify the types of information used or exposed in a system or pr <li>Identify the types of information used or exposed in a system or
otocol, some protocol, some of which can be used to identify a user or correlate to
of which can be used to identify a user or correlate to other contexts.</t> other contexts.</li>
</li> <li>Partition data to minimize the amount of user-identifying or
<li> correlatable information in any given context to only include what is
<t>Partition data to minimize the amount of user-identifying or correl necessary for that context and prevent the sharing of data across
atable contexts wherever possible.</li>
information in any given context to only include what is necessary for that
context, and prevent the sharing of data across contexts wherever possible.</t>
</li>
</ol> </ol>
<t>The most impactful types of information to partition are (a) user-ident <t>The most impactful types of information to partition are (a)
ifying information, user-identifying information, such as user identifiers (including
such as user identifiers (including account names or IP addresses) that can be account names or IP addresses) that can be linked and (b)
linked and (b) non-user-identifying information (including content a user non-user-identifying information (including content a user generates or
generates or accesses), which can be often sensitive when combined with a user i accesses), which can be often sensitive when combined with a user
dentifier.</t> identifier.</t>
<t>In this section, we discuss considerations for partitioning these types of information.</t> <t>In this section, we discuss considerations for partitioning these types of information.</t>
<section anchor="user-identifying-information"> <section anchor="user-identifying-information">
<name>User-Identifying Information</name> <name>User-Identifying Information</name>
<t>User data can itself be user-identifying, in which case it should be <t>User data can itself be user-identifying, in which case it should
treated as an identifier. be treated as an identifier. For example, Oblivious DoH and Oblivious
For example, Oblivious DoH and Oblivious HTTP partition the client IP address an HTTP partition the client IP address and client request data into
d client request data into separate contexts, thereby ensuring that no entity beyond the client
separate contexts, thereby ensuring that no entity beyond the client can observe can observe both. Collusion across contexts could reverse this
both. Collusion across contexts partitioning and cause non-user-identifying information to become
could reverse this partitioning, but can also promote non-user-identifying infor user-identifying information. For example, in CONNECT proxy systems tha
mation to user-identifying. t use
For example, in CONNECT proxy systems that use QUIC, the QUIC connection ID is i QUIC, the QUIC connection ID is inherently non-user-identifying since
nherently non-user-identifying it is generated randomly (<xref section="5.1" sectionFormat="of"
since it is generated randomly (<xref section="5.1" sectionFormat="comma" target target="RFC9000"/>). However, if combined with another context that
="QUIC"/>). However, if combined with another context that has user-identifying has user-identifying information such as the client IP address, the
information such as the client IP address, the QUIC connection ID can become use QUIC connection ID can become user-identifying information.</t>
r-identifying information.</t> <t>Some information is innate to client user-agents, including details
<t>Some information is innate to client user-agents, including details o of the network location and implementation of protocols in hardware
f implementation of and software. This information can be used to construct
protocols in hardware and software, and network location. This information can b user-identifying information, which is a process sometimes referred to
e used to construct as "fingerprinting". Depending on the application and system
user-identifying information, which is a process sometimes referred to as finger constraints, users may not be able to prevent fingerprinting in
printing. privacy contexts. As a result, fingerprinting information, when
Depending on the application and system constraints, users may not be able to pr combined with non-user-identifying user data, could turn that
event fingerprinting otherwise innocuous user data into user-identifying information.</t>
in privacy contexts. As a result, fingerprinting information, when combined with
non-user-identifying
user data, could promote user data to user-identifying information.</t>
</section> </section>
<section anchor="selecting-client-identifiers"> <section anchor="selecting-client-identifiers">
<name>Selecting Client Identifiers</name> <name>Selecting Client Identifiers</name>
<t>The selection of client identifiers used in the contexts used for pri <t>The selection of client identifiers used in the contexts used for
vacy partitioning has a large privacy partitioning has a large impact on the effectiveness of
impact on the effectiveness of partitioning. Identifier selection can either und partitioning. Identifier selection can either undermine or improve the
ermine or improve value of partitioning. Generally, each context involves some form of
the value of partitioning. Generally, each context involves some form of client client identifier, which might be directly associated with a client
identifier, identity but can also be a pseudonym or a random one-time
which might be directly associated with a client identity, but can also be a pse identifier.</t>
udonym <t>Using the same client identifier across multiple contexts can
or a random one-time identifier.</t> partly or wholly undermine the effectiveness of partitioning by
<t>Using the same client identifier across multiple contexts can partly allowing the various contexts to be linked back to the same client.
or wholly undermine the For example, if a client uses proxies as described in <xref
effectiveness of partitioning, by allowing the various contexts to be linked bac target="masque"/> to separate connections but uses the same email
k to the same client. address to authenticate to two servers in different contexts, those
For example, if a client uses proxies as described in <xref target="masque"/> to actions can be linked back to the same client. While this does not
separate connections, but uses undermine all of the partitioning achieved through proxying (the
the same email address to authenticate to two servers in different contexts, tho contexts along the network path still cannot correlate the client
se actions can be linked identity and what servers are being accessed), the overall effect of
back to the same client. While this does not undermine all of the partitioning a partitioning is diminished.</t>
chieved through
proxying (the contexts along the network path still cannot correlate the client
identity and
what servers are being accessed), the overall effect of partitioning is diminish
ed.</t>
<t>When possible, using per-context unique client identifiers provides b etter partitioning properties. <t>When possible, using per-context unique client identifiers provides b etter partitioning properties.
For example, a client can use a unique email address as an account identifier wi th each different For example, a client can use a unique email address as an account identifier wi th each different
server it needs to log into. The same approach can apply across many layers, as seen with server it needs to log into. The same approach can apply across many layers, as seen with
per-network MAC address randomization <xref target="I-D.ietf-madinas-mac-address -randomization"/>, use of per-network MAC address randomization <xref target="I-D.ietf-madinas-mac-address -randomization"/>, use of
multiple temporary IP addresses across connections and over time <xref target="R FC8981"/>, and use of multiple temporary IP addresses across connections and over time <xref target="R FC8981"/>, and use of
unique per-subscription identifiers for HTTP Web Push <xref target="RFC8030"/>.< /t> unique per-subscription identifiers for HTTP Web Push <xref target="RFC8030"/>.< /t>
</section> </section>
<section anchor="incorrect-or-incomplete-partitioning"> <section anchor="incorrect-or-incomplete-partitioning">
<name>Incorrect or Incomplete Partitioning</name> <name>Incorrect or Incomplete Partitioning</name>
<t>Privacy partitioning can be applied incorrectly or incompletely. Cont <t>Privacy partitioning can be applied incorrectly or
exts may contain incompletely. Contexts may contain more user-identifying information
more user-identifying information than desired, or some information in a context than desired, or some information in a context may be more
may be more user-identifying user-identifying than intended. Moreover, splitting user-identifying
than intended. Moreover, splitting user-identifying information over multiple co information over multiple contexts has to be done with care, as
ntexts has to be done creating more contexts can increase the number of entities that need
with care, as creating more contexts can increase the number of entities that ne to be trusted to not collude. Nevertheless, partitions can help
ed to be trusted to not collude. improve the client's privacy posture when applied carefully.</t>
Nevertheless, partitions can help improve the client's privacy posture when appl <t>Evaluating and qualifying the resulting privacy of a system or
ied carefully.</t> protocol that applies privacy partitioning depends on the contexts
<t>Evaluating and qualifying the resulting privacy of a system or protoc that exist and the types of user-identifying information in each
ol that applies privacy partitioning depends context. Such evaluation is helpful for identifying ways in which
on the contexts that exist and the types of user-identifying information in each systems or protocols can improve their privacy posture. For example,
context. Such evaluation is consider DNS over HTTPS <xref target="RFC8484"/>, which produces a
helpful for identifying ways in which systems or protocols can improve their pri single context that contains both the client IP address and client
vacy posture. For example, query. One application of privacy partitioning results in ODoH, which
consider DNS-over-HTTPS <xref target="DOH"/>, which produces a single context wh produces two contexts, one with the client IP address and the other
ich contains both the client IP with the client query.</t>
address and client query. One application of privacy partitioning results in ODo
H, which produces two contexts,
one with the client IP address and the other with the client query.</t>
</section> </section>
<section anchor="selecting-information-within-a-context"> <section anchor="selecting-information-within-a-context">
<name>Selecting Information Within a Context</name> <name>Selecting Information within a Context</name>
<t>Recognizing potential applications of privacy partitioning requires i <t>Recognizing potential applications of privacy partitioning requires
dentifying the contexts in use, the information identifying the contexts in use, the information exposed in a context,
exposed in a context, and the intent of information exposed in a context. Unfort and the intent of information exposed in a context. Unfortunately,
unately, determining what determining what information to include in a given context is a
information to include in a given context is a non-trivial task. In principle, t non-trivial task. In principle, the information contained in a context
he information contained should be fit for purpose. As such, new systems or protocols developed
in a context should be fit for purpose. As such, new systems or protocols develo should aim to ensure that all information exposed in a context serves
ped should aim to as few purposes as possible. Designing with this principle from the
ensure that all information exposed in a context serves as few purposes as possi start helps mitigate issues that arise if users of the system or
ble. Designing with this protocol inadvertently ossify on the information available in
principle from the start helps mitigate issues that arise if users of the system contexts. Legacy systems that have ossified on information available
or protocol inadvertently in contexts may be difficult to change in practice. As an example,
ossify on the information available in contexts. Legacy systems that have ossifi many existing anti-abuse systems depend on some client identifier,
ed on information available such as the client IP address, coupled with client data to provide
in contexts may be difficult to change in practice. As an example, many existing value. Partitioning contexts in these systems such that they no longer
anti-abuse systems determine the client identity requires new solutions to the anti-abuse
depend on some client identifier such as client IP address, coupled with client problem.</t>
data, to provide
value. Partitioning contexts in these systems such that they no longer determine
the client identity requires new
solutions to the anti-abuse problem.</t>
</section> </section>
</section> </section>
<section anchor="limits"> <section anchor="limits">
<name>Limits of Privacy Partitioning</name> <name>Limits of Privacy Partitioning</name>
<t>Privacy partitioning aims to increase user privacy, though as stated, i <t>Privacy partitioning aims to increase user privacy, though, as
t is merely one of possibly many stated, it is merely one of possibly many architectural tools that help
architectural tools that help manage privacy risks. Understanding manage privacy risks. Understanding the limits of its benefits requires
the limits of its benefits requires a more comprehensive analysis of the system a more comprehensive analysis of the system in question. Such analysis
in question. also helps determine whether or not the tool has been applied
Such analysis also helps determine whether or not the tool has been applied corr correctly. In particular, the value of privacy partitioning depends on
ectly. In particular, numerous factors, including, though not limited to, the following: </t>
the value of privacy partitioning depends on numerous factors, including, though <ul><li>non-collusion
not limited to:</t> across contexts and</li> <li>the type of information exposed in each
<ul spacing="normal"> context.</li></ul>
<li> <t>We elaborate on each in the following sections.</t>
<t>Non-collusion across contexts; and</t>
</li>
<li>
<t>The type of information exposed in each context.</t>
</li>
</ul>
<t>We elaborate on each below.</t>
<section anchor="violations-by-collusion"> <section anchor="violations-by-collusion">
<name>Violations by Collusion</name> <name>Violations by Collusion</name>
<t>Privacy partitions ensure that only the client, i.e., the entity whic <t>Privacy partitions ensure that only the client, i.e., the entity
h is responsible for partitioning, that is responsible for partitioning, can independently link all
can independently link all user-specific information. No other entity individual user-specific information. No other entity individually knows how to
ly link all the user-specific information as long as they do not collude
knows how to link all the user-specific information as long as they do not collu with each other across contexts. Thus, non-collusion is a fundamental
de with each other requirement for privacy partitioning to offer meaningful privacy for
across contexts. Thus, non-collusion is a fundamental requirement for privacy pa end users. In particular, the trust relationships that users have with
rtitioning different parties affect the resulting impact on the user's
to offer meaningful privacy for end-users. In particular, the trust relationship privacy.</t>
s that users have <t>As an example, consider Oblivious HTTP (OHTTP), wherein the Oblivious
with different parties affect the resulting impact on the user's privacy.</t> Relay knows
<t>As an example, consider OHTTP, wherein the Oblivious Relay knows the the client identity but not the client data, and the Oblivious Gateway
client identity but not knows the client data but not the client identity. If the Oblivious
the client data, and the Oblivious Gateway knows the client data but not the cli Relay and Gateway collude, they can link client identity and data
ent identity. together for each request and response transaction by simply observing
If the Oblivious Relay and Gateway collude, they can link client identity and da requests in transit.</t>
ta together <t>It is not currently possible to guarantee with technical protocol
for each request and response transaction by simply observing requests in transi measures that two entities are not colluding. Even if two entities do
t.</t> not collude directly, if both entities reveal information to other
<t>It is not currently possible to guarantee with technical protocol mea parties, it will not be possible to guarantee that the information
sures that two won't be combined. However, there are some mitigations that can be
entities are not colluding. Even if two entities do not collude directly, if bot applied to reduce the risk of collusion happening in practice:</t>
h entities reveal
information to other parties, it will not be possible to guarantee that the info
rmation won't
be combined. However, there are some mitigations that can be applied
to reduce the risk of collusion happening in practice:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Policy and contractual agreements between entities involved in
<t>Policy and contractual agreements between entities involved in pa partitioning to disallow logging or sharing of data, along with
rtitioning to disallow auditing to validate that the policies are being followed. For
logging or sharing of data, along with auditing to validate that the policies ar cases where logging is required (such as for service operation),
e being followed. such logged data should be minimized and anonymized to prevent it
For cases where logging is required (such as for service operation), such logged from being useful for collusion.</li>
data should <li>Protocol requirements to make collusion or data sharing more
be minimized and anonymized to prevent it from being useful for collusion.</t> difficult.</li>
</li> <li>Adding more partitions and contexts to make it increasingly
<li> difficult to collude with enough parties to recover identities.</li>
<t>Protocol requirements to make collusion or data sharing more diff
icult.</t>
</li>
<li>
<t>Adding more partitions and contexts, to make it increasingly diff
icult to collude with
enough parties to recover identities.</t>
</li>
</ul> </ul>
</section> </section>
<section anchor="violations-by-insufficient-or-incorrect-partitioning"> <section anchor="violations-by-insufficient-or-incorrect-partitioning">
<name>Violations by Insufficient or Incorrect Partitioning</name> <name>Violations by Insufficient or Incorrect Partitioning</name>
<t>Insufficient or incorrect application of privacy partitioning can les <t>Insufficient or incorrect application of privacy partitioning can
sen or negate benefits to users. lessen or negate benefits to users. In particular, it is possible to
In particular, it is possible to apply partitioning in a way that is either insu apply partitioning in a way that is either insufficient or incorrect
fficient or incorrect for meaningful privacy. For example, partitioning at one layer in the
for meaningful privacy. For example, partitioning at one layer in the stack can stack can fail to account for linkable information at different layers
fail to account for in the stack. Privacy violations can stem from partitioning failures
linkable information at different layers in the stack. Privacy violations can st in a multitude of ways, some of which are described in the following
em from partitioning sections.</t>
failures in a multitude of ways, some of which are described below.</t>
<section anchor="violations-from-application-information"> <section anchor="violations-from-application-information">
<name>Violations from Application Information</name> <name>Violations from Application Information</name>
<t>Partitioning at the network layer can be insufficient when the appl <t>Partitioning at the network layer can be insufficient when the
ication layer fails to properly application layer fails to properly partition. As an example,
partition. As an example, consider OHTTP used for the purposes of hiding consider OHTTP used for the purposes of hiding client-identifying
client-identifying information for a browser telemetry system. It is entirely po information for a browser telemetry system. It is entirely possible
ssible for reports for reports in such a telemetry system to contain both
in such a telemetry system to contain both client-specific telemetry data, such client-specific telemetry data, such as information about their
as information specific browser instance, as well as client-identifying
about their specific browser instance, as well as client-identifying information information, such as the client's email address, location, or IP
, such as the client's address. Even though OHTTP separates the client IP address from the
email address, location, or IP address. Even though OHTTP separates the client I server via a relay, the server can still learn this directly from
P address from the the client's telemetry report.</t>
server via a relay, the server can still learn this directly from the client's t
elemetry report.</t>
</section> </section>
<section anchor="violations-from-network-information"> <section anchor="violations-from-network-information">
<name>Violations from Network Information</name> <name>Violations from Network Information</name>
<t>It is also possible to inadequately partition at the network layer. <t>It is also possible to inadequately partition at the network
As an example, consider both TLS Encrypted Client Hello (ECH) <xref target="I-D layer. As an example, consider both TLS Encrypted Client Hello (ECH)
.ietf-tls-esni"/> <xref target="I-D.ietf-tls-esni"/> and VPNs. ECH uses cryptographic
and VPNs. ECH uses cryptographic protection (encryption) to hide information fro protection (encryption) to hide information from unauthorized
m unauthorized parties, parties, but both clients and servers (two entities) can link
but both clients and servers (two entities) can link user-specific data to user- user-specific data to a user-specific identifier (IP address).
specific identifier (IP address). Similarly, while VPNs hide identifiers from end servers, the VPN
Similarly, while VPNs hide identifiers from end servers, the VPN server can stil server can still see the identifiers of both the client and
l see the identifiers of both the server. Applying privacy partitioning would advocate for at least
client and server. Applying privacy partitioning would advocate for at least two two additional entities to avoid revealing both identity (who) and
additional entities to avoid user actions (what) from each involved party.</t>
revealing both identity (who) and user actions (what) from each involved party.<
/t>
</section> </section>
<section anchor="violations-from-side-channels"> <section anchor="violations-from-side-channels">
<name>Violations from Side Channels</name> <name>Violations from Side Channels</name>
<t>Beyond the information that is intentionally revealed by applying p <t>Beyond the information that is intentionally revealed by applying
rivacy partitioning, it is also possible privacy partitioning, it is also possible for the information to be
for the information to be unintentionally revealed through side channels. For ex unintentionally revealed through side channels. For example, in the
ample, in the two-hop two-hop proxy arrangement described in <xref target="masque"/>,
proxy arrangement described in <xref target="masque"/>, Proxy A sees and proxies Proxy A sees and proxies TLS data between the client and Proxy
TLS data between the client and B. While it does not directly learn information that Proxy B sees,
Proxy B. While it does not directly learn information that Proxy B sees, it does it does learn information through metadata, such as the timing and
learn information through size of encrypted data being proxied. Traffic analysis could be
metadata, such as the timing and size of encrypted data being proxied. Traffic a exploited to learn more information from such metadata, including,
nalysis could be exploited in some cases, application data that Proxy A was never meant to
to learn more information from such metadata, including, in some cases, applicat see. Although privacy partitioning does not obviate such attacks, it
ion data that Proxy A was does increase the cost necessary to carry them out in practice. See
never meant to see. Although privacy partitioning does not obviate such attacks, <xref target="security-considerations"/> for more discussion on this
it does increase the cost topic.</t>
necessary to carry them out in practice. See <xref target="security-consideratio
ns"/> for more discussion on this topic.</t>
</section> </section>
<section anchor="identifying-partitions"> <section anchor="identifying-partitions">
<name>Identifying Partitions</name> <name>Identifying Partitions</name>
<t>While straightforward violations of user privacy that stem from ins <t>While straightforward violations of user privacy that stem from
ufficient partitioning may seem straightforward insufficient partitioning may seem straightforward to mitigate, it
to mitigate, it remains an open problem to rigorously determine what information remains an open problem to rigorously determine what information
needs to be partitioned for meaningful needs to be partitioned for meaningful privacy and to implement it
privacy, and to implement it in a way that achieves the desired properties. In e in a way that achieves the desired properties. In essence, it is
ssence, it is difficult to determine difficult to determine whether a certain set of information reveals
whether a certain set of information reveals "too much" about a specific user, a "too much" about a specific user, and it is similarly challenging to
nd it is similarly challenging to determine determine whether or not an implementation of partitioning works as
whether or not an implementation of partitioning works as intended. There is amp intended. There is ample evidence of data being assumed "private" or
le evidence of data being assumed "private" "anonymous" but, in hindsight, winds up revealing too much
or "anonymous" but, in hindsight, winds up revealing too much information such t information such that it allows one to link back to individual
hat it allows one to link back to individual clients; see <xref target="DataSetReconstruction"/> and <xref
clients; see <xref target="DataSetReconstruction"/> and <xref target="CensusReco target="CensusReconstruction"/> for more examples of this in the
nstruction"/> real world.</t>
for more examples of this in the real world.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="partitioning-impacts"> <section anchor="partitioning-impacts">
<name>Partitioning Impacts</name> <name>Partitioning Impacts</name>
<t>Applying privacy partitioning to communication protocols leads to a sub <t>Applying privacy partitioning to communication protocols leads to a
stantial change in communication patterns. substantial change in communication patterns. For example, instead of
For example, instead of sending traffic directly to a service, essentially all u sending traffic directly to a service, essentially all user traffic is
ser traffic is routed through routed through a set of intermediaries, possibly adding more end-to-end
a set of intermediaries, possibly adding more end-to-end round trips in the proc round trips in the process (depending on the system and protocol). This
ess (depending on the system has a number of practical implications, described below.</t>
and protocol). This has a number of practical implications, described below.</t> <ol spacing="normal">
<ol spacing="normal" type="1"><li> <li><t>Service operational or management challenges: Information that
<t>Service operational or management challenges. Information that is t is usually passively observed in the network or metadata that
raditionally passively observed in the has been unintentionally revealed to the service provider will no
network or metadata that has been unintentionally revealed to the service provid longer be available; for example, this can impact existing security
er cannot be used anymore procedures such as application rate limiting or DDoS mitigation.
for e.g., existing security procedures such as application rate limiting or DDoS Current network management techniques deployed often rely on
mitigation. information that is exposed by typical traffic that lacks guarantees
However, network management techniques deployed at present often rely on informa or accuracy.</t>
tion that is exposed by <t>Privacy partitioning provides an opportunity for improvements in
most traffic but without any guarantees that the information is accurate. </t> these management techniques by enabling active exchange of information
<t> with each entity in a privacy-preserving way and requesting exactly
Privacy partitioning provides an opportunity for improvements in these managemen the information needed for a specific task or function rather than
t techniques by relying on information derived from a limited set of unintentionally
enabling active exchange of information with each entity in a privacy-preserving revealed information that cannot be guaranteed to be available and may
way and requesting be removed in the future.</t></li>
exactly the information needed for a specific task or function rather than relyi
ng on the assumption that <li><t>Varying performance effects and costs:
are derived from a limited set of unintentionally revealed information which can Depending on how context separation is done, privacy
not be guaranteed to be partitioning may affect application performance. As an example,
present and may disappear at any time in future.</t> Privacy Pass introduces an entire end-to-end round trip to issue a
</li> token before it can be redeemed, thereby decreasing performance. In
<li> contrast, while systems like CONNECT proxying may seem like they would
<t>Varying performance effects and costs. Depending on how context sep reduce performance, oftentimes the highly optimized nature of
aration is done, privacy partitioning may proxy-to-proxy paths leads to improved performance.</t>
affect application performance. As an example, Privacy Pass introduces an entire <t>Reduced performance can be a reason that protocols and deployments
end-to-end round will not apply privacy partitioning. For example, HTTPS connection
trip to issue a token before it can be redeemed, thereby decreasing performance. reuse (<xref section="9.1.1" sectionFormat="of" target="RFC9113"/>)
In contrast, while allows clients to use an existing HTTPS session created for one origin
systems like CONNECT proxying may seem like they would regress performance, ofte to interact with different origins (provided that the original origin
ntimes the highly is authoritative for these alternative origins). Reusing connections
optimized nature of proxy-to-proxy paths leads to improved performance. </t> saves the cost of connection establishment but means that the server
<t> can now link the client's activity with these two or more origins
Performance may also push back against the desire to apply privacy partitioning. together. Applying privacy partitioning would prevent this, but
For example, HTTPS typically at the cost of performance.</t>
connection reuse <xref section="9.1.1" sectionFormat="comma" target="HTTP2"/> al <t>In general, while performance and privacy trade-offs are often cast
lows clients to use an existing HTTPS session created as a zero-sum game, in practice this is often not the case. The
for one origin to interact with different origins (provided the original origin relationship between privacy and performance varies depending on a
is authoritative for number of related factors, such as application characteristics,
these alternative origins). Reusing connections saves the cost of connection est network path properties, and so on.</t>
ablishment, but means that
the server can now link the client's activity with these two or more origins tog
ether. Applying privacy
partitioning would prevent this, while typically at the cost of less performance
. </t>
<t>
In general, while performance and privacy tradeoffs are often cast as a zero-sum
game, in practice this
is often not the case. The relationship between privacy and performance varies d
epending on a number
of related factors, such as application characteristics, network path properties
, and so on.</t>
</li>
<li>
<t>Increased attack surface. Even in the event that information is ade
quately partitioned across
non-colluding parties, the resulting effects on the end-user may not always be p
ositive. For example,
using OHTTP as a basis for illustration, consider a hypothetical scenario where
the Oblivious
Gateway has an implementation flaw that causes all of its decrypt requests to be
inappropriately logged to a public or otherwise compromised location. Moreover,
assume
that the Target Resource for which these requests are destined does not have suc
h an
implementation flaw. Applications which use OHTTP with this flawed Oblivious Gat
eway to
interact with the Target Resource risk their user request information being made
public,
albeit in a way that is decoupled from user identifying information, whereas app
lications
that do not use OHTTP to interact with the Target Resource do not risk this type
of disclosure.</t>
</li>
<li>
<t>Centralization. Depending on the protocol and system, as well as th
e desired privacy properties, the
use of partitioning may inherently force centralization to a selected set of tru
sted participants.
As an example, the impact of OHTTP on end-user privacy generally increases propo
rtionally to the
number of users that exist behind a given Oblivious Relay. That is, the probabil
ity of an Oblivious
Gateway determining the client associated with a request forwarded through an Ob
livious Relay decreases
as the number of possible clients behind the Oblivious Relay increases. This tra
deoff encourages
the centralization of the Oblivious Relays.</t>
</li> </li>
<li><t>Increased attack surface:
Even in the event that information is adequately partitioned
across non-colluding parties, the resulting effects on the end user
may not always be positive. For example, using OHTTP as a basis for
illustration, consider a hypothetical scenario where the Oblivious
Gateway has an implementation flaw that causes all of its decrypt
requests to be inappropriately logged in a public or otherwise
compromised location. Moreover, assume that the Target Resource for
which these requests are destined does not have such an implementation
flaw. Applications that use OHTTP with this flawed Oblivious Gateway
to interact with the Target Resource risk their user request
information being made public, albeit in a way that is decoupled from
user identifying information, whereas applications that do not use
OHTTP to interact with the Target Resource do not risk this type of
disclosure.</t></li>
<li><t>Centralization: Depending on the protocol and system, as well
as the desired privacy properties, the use of partitioning may
inherently force centralization to a selected set of trusted
participants. As an example, the impact of OHTTP on end-user privacy
generally increases proportionally to the number of users that exist
behind a given Oblivious Relay. That is, the probability of an
Oblivious Gateway determining the client associated with a request
forwarded through an Oblivious Relay decreases as the number of
possible clients behind the Oblivious Relay increases. This trade-off
encourages the centralization of the Oblivious Relays.</t></li>
</ol> </ol>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="limits"/> discusses some of the limitations of privacy pa <t><xref target="limits"/> discusses some of the limitations of privacy
rtitioning in practice, and advocates for holistic partitioning in practice and advocates for holistic analysis to
analysis to understand the extent to which privacy partitioning offers meaningfu understand the extent to which privacy partitioning offers meaningful
l privacy improvements. privacy improvements. Applied correctly, partitioning helps improve an
Applied correctly, partitioning helps improve an end-user's privacy posture, the end-user's privacy posture, thereby making violations harder to do via
reby making violations harder to technical, social, or policy means. For example, side channels such as
do via technical, social, or policy means. For example, side channels such as tr traffic analysis <xref target="I-D.irtf-pearg-website-fingerprinting"/>
affic analysis or timing analysis are still possible and can allow an unauthorized
<xref target="I-D.irtf-pearg-website-fingerprinting"/> or timing analysis are st entity to learn information about a context they are not a participant
ill possible and can allow of. Proposed mitigations for these types of attacks, e.g., padding
an unauthorized entity to learn information about a context they are not a parti application traffic or generating fake traffic, can be very expensive
cipant of. and are therefore not typically applied in practice. Nevertheless,
Proposed mitigations for these types of attacks, e.g., padding application traff privacy partitioning moves the threat vector from one that has direct
ic or generating access to user-specific information to one that requires more effort,
fake traffic, can be very expensive and are therefore not typically applied in p e.g., computational resources, to violate end-user privacy.</t>
ractice.
Nevertheless, privacy partitioning moves the threat vector from one that has dir
ect access to
user-specific information to one which requires more effort, e.g., computational
resources,
to violate end-user privacy.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9297" to="CONNECT-UDP"/>
<displayreference target="RFC9484" to="CONNECT-IP"/>
<displayreference target="RFC9458" to="OHTTP"/>
<displayreference target="RFC9180" to="HPKE"/>
<displayreference target="RFC9230" to="ODOH"/>
<displayreference target="RFC9000" to="QUIC"/>
<displayreference target="I-D.ietf-madinas-mac-address-randomization" to="RA
NDOM-MAC"/>
<displayreference target="RFC8484" to="DOH"/>
<displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
<displayreference target="RFC9113" to="HTTP2"/>
<displayreference target="I-D.irtf-pearg-website-fingerprinting" to="FINGERP
INT"/>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="CensusReconstruction" target="https://www.census.gov/da ta/academy/webinars/2021/disclosure-avoidance-series/simulated-reconstruction-ab etted-re-identification-attack-on-the-2010-census.html"> <reference anchor="CensusReconstruction" target="https://www.census.gov/da ta/academy/webinars/2021/disclosure-avoidance-series/simulated-reconstruction-ab etted-re-identification-attack-on-the-2010-census.html">
<front> <front>
<title>The Census Bureau's Simulated Reconstruction-Abetted Re-identif <title>The Census Bureau's Simulated Reconstruction-Abetted
ication Attack on the 2010 Census</title> Re-identification Attack on the 2010 Census</title>
<author> <author>
<organization/> <organization>United States Consensus Bureau</organization>
</author> </author>
<date>n.d.</date> <date month="May" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="DECOUPLING"> <reference anchor="DECOUPLING">
<front> <front>
<title>The decoupling principle: a practical privacy framework</title> <title>The decoupling principle: a practical privacy framework</title>
<author fullname="Paul Schmitt" initials="P." surname="Schmitt"> <author fullname="Paul Schmitt" initials="P." surname="Schmitt">
<organization>University of Hawai'i</organization> <organization>University of Hawai'i</organization>
</author> </author>
<author fullname="Jana Iyengar" initials="J." surname="Iyengar"> <author fullname="Jana Iyengar" initials="J." surname="Iyengar">
<organization>Fastly</organization> <organization>Fastly</organization>
</author> </author>
<author fullname="Christopher Wood" initials="C." surname="Wood"> <author fullname="Christopher Wood" initials="C." surname="Wood">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
</author> </author>
<author fullname="Barath Raghavan" initials="B." surname="Raghavan"> <author fullname="Barath Raghavan" initials="B." surname="Raghavan">
<organization>USC</organization> <organization>USC</organization>
</author> </author>
<date month="November" year="2022"/> <date month="November" year="2022"/>
</front> </front>
<seriesInfo name="Proceedings of the 21st ACM Workshop on Hot Topics in" value="Networks"/> <refcontent>Proceedings of the 21st ACM Workshop on Hot Topics in Networ ks</refcontent>
<seriesInfo name="DOI" value="10.1145/3563766.3564112"/> <seriesInfo name="DOI" value="10.1145/3563766.3564112"/>
<refcontent>ACM</refcontent>
</reference>
<reference anchor="RFC6973">
<front>
<title>Privacy Considerations for Internet Protocols</title>
<author fullname="A. Cooper" initials="A." surname="Cooper"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="J. Morris" initials="J." surname="Morris"/>
<author fullname="M. Hansen" initials="M." surname="Hansen"/>
<author fullname="R. Smith" initials="R." surname="Smith"/>
<date month="July" year="2013"/>
<abstract>
<t>This document offers guidance for developing privacy consideratio
ns for inclusion in protocol specifications. It aims to make designers, implemen
ters, and users of Internet protocols aware of privacy-related design choices. I
t suggests that whether any individual RFC warrants a specific privacy considera
tions section will depend on the document's content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6973"/>
<seriesInfo name="DOI" value="10.17487/RFC6973"/>
</reference>
<reference anchor="CONNECT-UDP">
<front>
<title>HTTP Datagrams and the Capsule Protocol</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="L. Pardue" initials="L." surname="Pardue"/>
<date month="August" year="2022"/>
<abstract>
<t>This document describes HTTP Datagrams, a convention for conveyin
g multiplexed, potentially unreliable datagrams inside an HTTP connection.</t>
<t>In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC D
ATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, H
TTP Datagrams can be sent using the Capsule Protocol, which is a more general co
nvention for conveying data in HTTP connections.</t>
<t>HTTP Datagrams and the Capsule Protocol are intended for use by H
TTP extensions, not applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9297"/>
<seriesInfo name="DOI" value="10.17487/RFC9297"/>
</reference>
<reference anchor="CONNECT-IP">
<front>
<title>Proxying IP in HTTP</title>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<author fullname="David Schinazi" initials="D." surname="Schinazi">
<organization>Google LLC</organization>
</author>
<author fullname="Alex Chernyakhovsky" initials="A." surname="Chernyak
hovsky">
<organization>Google LLC</organization>
</author>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
<organization>Ericsson</organization>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund
">
<organization>Ericsson</organization>
</author>
<date day="28" month="April" year="2023"/>
<abstract>
<t>This document describes how to proxy IP packets in HTTP. This pr
otocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP p
ackets. More specifically, this document defines a protocol that allows an HTTP
client to create an IP tunnel through an HTTP server that acts as an IP proxy.
This document updates RFC 9298.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-ip-13
"/>
</reference> </reference>
<reference anchor="OHTTP">
<front>
<title>Oblivious HTTP</title>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Wood"
>
<organization>Cloudflare</organization>
</author>
<date day="25" month="August" year="2023"/>
<abstract>
<t> This document describes Oblivious HTTP, a protocol for forward
ing
encrypted HTTP messages. Oblivious HTTP allows a client to make
multiple requests to an origin server without that server being able
to link those requests to the client or to identify the requests as
having come from the same client, while placing only limited trust in
the nodes used to forward the messages.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.697
</abstract> 3.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929
<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/> 7.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.948
<reference anchor="HPKE"> 4.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.945
<title>Hybrid Public Key Encryption</title> 8.xml"/>
<author fullname="R. Barnes" initials="R." surname="Barnes"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.918
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/> 0.xml"/>
<author fullname="B. Lipp" initials="B." surname="Lipp"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.923
<author fullname="C. Wood" initials="C." surname="Wood"/> 0.xml"/>
<date month="February" year="2022"/>
<abstract>
<t>This document describes a scheme for hybrid public key encryption
(HPKE). This scheme provides a variant of public key encryption of arbitrary-si
zed plaintexts for a recipient public key. It also includes three authenticated
variants, including one that authenticates possession of a pre-shared key and tw
o optional ones that authenticate possession of a key encapsulation mechanism (K
EM) private key. HPKE works for any combination of an asymmetric KEM, key deriva
tion function (KDF), and authenticated encryption with additional data (AEAD) en
cryption function. Some authenticated variants may not be supported by all KEMs.
We provide instantiations of the scheme using widely used and efficient primiti
ves, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key
derivation function (HKDF), and SHA2.</t>
<t>This document is a product of the Crypto Forum Research Group (CF
RG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9180"/>
<seriesInfo name="DOI" value="10.17487/RFC9180"/>
</reference>
<reference anchor="ODOH">
<front>
<title>Oblivious DNS over HTTPS</title>
<author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="T. Verma" initials="T." surname="Verma"/>
<author fullname="C.A. Wood" initials="C.A." surname="Wood"/>
<date month="June" year="2022"/>
<abstract>
<t>This document describes a protocol that allows clients to hide th
eir IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH)
messages. This improves privacy of DNS operations by not allowing any one server
entity to be aware of both the client IP address and the content of DNS queries
and answers.</t>
<t>This experimental protocol has been developed outside the IETF an
d is published here to guide implementation, ensure interoperability among imple
mentations, and enable wide-scale experimentation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9230"/>
<seriesInfo name="DOI" value="10.17487/RFC9230"/>
</reference>
<reference anchor="PRIVACYPASS">
<front>
<title>The Privacy Pass Architecture</title>
<author fullname="Alex Davidson" initials="A." surname="Davidson">
<organization>LIP</organization>
</author>
<author fullname="Jana Iyengar" initials="J." surname="Iyengar">
<organization>Fastly</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Wood"
>
<organization>Cloudflare</organization>
</author>
<date day="25" month="September" year="2023"/>
<abstract>
<t> This document specifies the Privacy Pass architecture and
requirements for its constituent protocols used for authorization
based on privacy-preserving authentication mechanisms. It describes
the conceptual model of Privacy Pass and its protocols, its security
and privacy goals, practical deployment models, and recommendations
for each deployment model that helps ensure the desired security and
privacy goals are fulfilled.
</t> <!-- [I-D.ietf-privacypass-architecture] Published as RFC 9576-->
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.957
</front> 6.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-architec
ture-16"/>
</reference>
<reference anchor="QUIC">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye
ngar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
mson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol. QU
IC provides applications with flow-controlled streams for structured communicati
on, low-latency connection establishment, and network path migration. QUIC inclu
des security measures that ensure confidentiality, integrity, and availability i
n a range of deployment circumstances. Accompanying documents describe the integ
ration of TLS for key negotiation, loss detection, and an exemplary congestion c
ontrol algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="I-D.ietf-madinas-mac-address-randomization">
<front>
<title>Randomized and Changing MAC Address state of affairs</title>
<author fullname="Juan-Carlos Zúñiga" initials="J. C." surname="Zúñiga
">
<organization>CISCO</organization>
</author>
<author fullname="Carlos J. Bernardos" initials="C. J." surname="Berna
rdos">
<organization>Universidad Carlos III de Madrid</organization>
</author>
<author fullname="Amelia Andersdotter" initials="A." surname="Andersdo
tter">
<organization>Safespring AB</organization>
</author>
<date day="11" month="January" year="2024"/>
<abstract>
<t> Internet privacy has become a major concern over the past few
years.
Users are becoming more aware that their online activity leaves a
vast digital footprint, that communications are not always properly
secured, and that their location and actions can be easily tracked.
One of the main factors for the location tracking issue is the wide
use of long-lasting identifiers, such as MAC addresses.
There have been several initiatives at the IETF and the IEEE 802 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.900
standards committees to overcome some of these privacy issues. This 0.xml"/>
document provides an overview of these activities, with the intention
to inform the technical community about them, and help coordinate
between present and future standardization activities.
</t> <!-- [I-D.ietf-madinas-mac-address-randomization] [QUIC] IESG state: RFC Ed
</abstract> Queue as of 7/30/24; updated to long version because missing editor role
</front> and not showing initials correctly -->
<seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address- <reference anchor="I-D.ietf-madinas-mac-address-randomization" target="htt
randomization-10"/> ps://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-
</reference> 12">
<reference anchor="RFC8981"> <front>
<front> <title>Randomized and Changing MAC Address state of affairs</title>
<title>Temporary Address Extensions for Stateless Address Autoconfigur <author initials="JC." surname="Zuniga" fullname="Juan-Carlos Zuniga">
ation in IPv6</title> <organization>CISCO</organization>
<author fullname="F. Gont" initials="F." surname="Gont"/> </author>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/> <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardo
<author fullname="T. Narten" initials="T." surname="Narten"/> s" role="editor">
<author fullname="R. Draves" initials="R." surname="Draves"/> <organization>Universidad Carlos III de Madrid</organization>
<date month="February" year="2021"/> </author>
<abstract> <author initials="A." surname="Andersdotter" fullname="Amelia Andersdot
<t>This document describes an extension to IPv6 Stateless Address Au ter">
toconfiguration that causes hosts to generate temporary addresses with randomize <organization>Safespring AB</organization>
d interface identifiers for each prefix advertised with autoconfiguration enable </author>
d. Changing addresses over time limits the window of time during which eavesdrop <date month="February" day="28" year="2024"/>
pers and other information collectors may trivially perform address-based networ </front>
k-activity correlation when the same address is employed for multiple transactio <seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-r
ns by the same host. Additionally, it reduces the window of exposure of a host a andomization-12"/>
s being accessible via an address that becomes revealed as a result of active co
mmunication. This document obsoletes RFC 4941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8981"/>
<seriesInfo name="DOI" value="10.17487/RFC8981"/>
</reference>
<reference anchor="RFC8030">
<front>
<title>Generic Event Delivery Using HTTP Push</title>
<author fullname="M. Thomson" initials="M." surname="Thomson"/>
<author fullname="E. Damaggio" initials="E." surname="Damaggio"/>
<author fullname="B. Raymor" initials="B." role="editor" surname="Raym
or"/>
<date month="December" year="2016"/>
<abstract>
<t>This document describes a simple protocol for the delivery of rea
l- time events to user agents. This scheme uses HTTP/2 server push.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8030"/>
<seriesInfo name="DOI" value="10.17487/RFC8030"/>
</reference>
<reference anchor="DOH">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<date month="October" year="2018"/>
<abstract>
<t>This document defines a protocol for sending DNS queries and gett
ing DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTT
P exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference> </reference>
<reference anchor="I-D.ietf-tls-esni">
<front>
<title>TLS Encrypted Client Hello</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Kazuho Oku" initials="K." surname="Oku">
<organization>Fastly</organization>
</author>
<author fullname="Nick Sullivan" initials="N." surname="Sullivan">
<organization>Cloudflare</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Wood"
>
<organization>Cloudflare</organization>
</author>
<date day="9" month="October" year="2023"/>
<abstract>
<t> This document describes a mechanism in Transport Layer Securit
y (TLS)
for encrypting a ClientHello message under a server public key.
Discussion Venues
This note is to be removed before publishing as an RFC. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.898
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.848
4.xml"/>
Source for this draft and an issue tracker can be found at <!-- [I-D.ietf-tls-esni] IESG state: I-D Exists 7/30/2024 -->
https://github.com/tlswg/draft-ietf-tls-esni <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tls-
(https://github.com/tlswg/draft-ietf-tls-esni). esni.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-17"/>
</reference>
<reference anchor="DataSetReconstruction"> <reference anchor="DataSetReconstruction">
<front> <front>
<title>Robust De-anonymization of Large Sparse Datasets</title> <title>Robust De-anonymization of Large Sparse Datasets</title>
<author fullname="Arvind Narayanan" initials="A." surname="Narayanan"> <author fullname="Arvind Narayanan" initials="A." surname="Narayanan">
<organization/> <organization/>
</author> </author>
<author fullname="Vitaly Shmatikov" initials="V." surname="Shmatikov"> <author fullname="Vitaly Shmatikov" initials="V." surname="Shmatikov">
<organization/> <organization/>
</author> </author>
<date month="May" year="2008"/> <date month="May" year="2008"/>
</front> </front>
<seriesInfo name="2008 IEEE Symposium on Security and Privacy (sp" value ="2008)"/> <refcontent>IEEE Symposium on Security and Privacy</refcontent>
<seriesInfo name="DOI" value="10.1109/sp.2008.33"/> <seriesInfo name="DOI" value="10.1109/sp.2008.33"/>
<refcontent>IEEE</refcontent>
</reference>
<reference anchor="HTTP2">
<front>
<title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
mson"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="Be
nfield"/>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the seman
tics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (H
TTP/2). HTTP/2 enables a more efficient use of network resources and a reduced l
atency by introducing field compression and allowing multiple concurrent exchang
es on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference> </reference>
<reference anchor="I-D.irtf-pearg-website-fingerprinting">
<front>
<title>Network-Based Website Fingerprinting</title>
<author fullname="Ian Goldberg" initials="I." surname="Goldberg">
<organization>University of Waterloo</organization>
</author>
<author fullname="Tao Wang" initials="T." surname="Wang">
<organization>HK University of Science and Technology</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Wood"
>
<organization>Cloudflare</organization>
</author>
<date day="8" month="September" year="2020"/>
<abstract>
<t> The IETF is well on its way to protecting connection metadata
with
protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in-
progress towards encrypting the TLS SNI. However, more work is
needed to protect traffic metadata, especially in the context of web
traffic. In this document, we survey Website Fingerprinting attacks,
which are a class of attacks that use machine learning techniques to
attack web privacy, and highlight metadata leaks used by said
attacks. We also survey proposed mitigations for such leakage and
discuss their applicability to IETF protocols such as TLS, QUIC, and
HTTP. We endeavor to show that Website Fingerprinting attacks are a
serious problem that affect all Internet users, and we pose open
problems and directions for future research in this area.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
</abstract> 3.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-pearg-website-finger <!-- [I-D.irtf-pearg-website-fingerprinting] IESG state: Expired as of 7/3
printing-01"/> 0/24-->
</reference> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-pear
g-website-fingerprinting.xml"/>
</references> </references>
<?line 834?> <section numbered="false" anchor="iab-members">
<name>IAB Members at the Time of Approval</name>
<t>Internet Architecture Board members at the time this document was
approved for publication were:</t>
<ul empty="true" spacing="compact" bare="false" indent="3">
<li>
<t><contact fullname="Dhruv Dhody"/></t>
</li>
<li>
<t><contact fullname="Lars Eggert"/></t>
</li>
<li>
<t><contact fullname="Wes Hardaker"/></t>
</li>
<li>
<t><contact fullname="Cullen Jennings"/></t>
</li>
<li>
<t><contact fullname="Mallory Knodel"/></t>
</li>
<li>
<t><contact fullname="Suresh Krishnan"/></t>
</li>
<li>
<t><contact fullname="Mirja Kühlewind"/></t>
</li>
<li>
<t><contact fullname="Tommy Pauly"/></t>
</li>
<li>
<t><contact fullname="Alvaro Retana"/></t>
</li>
<li>
<t><contact fullname="David Schinazi"/></t>
</li>
<li>
<t><contact fullname="Christopher Wood"/></t>
</li>
<li>
<t><contact fullname="Qin Wu"/></t>
</li>
<li>
<t><contact fullname="Jiankang Yao"/></t>
</li>
</ul>
</section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank Martin Thomson, Eliot Lear, Mark Nottingham, Nie <t>We would like to thank <contact fullname="Martin Thomson"/>, <contact
ls ten Oever, Vittorio Bertola, fullname="Eliot Lear"/>, <contact fullname="Mark Nottingham"/>, <contact
Antoine Fressancourt, Cullen Jennings, and Dhruv Dhody for their reviews and fee fullname="Niels ten Oever"/>, <contact fullname="Vittorio Bertola"/>,
dback.</t> <contact fullname="Antoine Fressancourt"/>, <contact fullname="Cullen
Jennings"/>, and <contact fullname="Dhruv Dhody"/> for their reviews and
feedback.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1923bbRrbge30FlvohUpuk7aQviTPpbll22ppOYp3I6ax5
mbVAokjiGATYKFAKY7u/bN7mx2Zf6wKAshTLM52ew4fEIoG67Nq175fpdGq6
sqvsk+zoIm/hn2VTl/Uqy12W19lpu1iXnV10u9Zmy6bNLtryKl/sj0w+n7f2
qv9W8sgi7+yqafdPsrJeNsZ1rc03T7Lz06fGFM2izjcwa9Hmy25a5vPplt+b
bqMBp49+b2CSz8xru79u2gLerjvb1rabPsMXjcl33bppn5hsajL4LHdVxQN/
W7b/mWd/+9//a13Z67Iu6OemXeV1+XOOwz/Jnrflwrmmzr63zuawVXrGbvKy
epJt8P3Z652V9/9i5enZotkMp3vVbDb77CLfVfuRmU6328rGo3dbfPIvOX4/
PuDZui1d12zXts1OZ9mPTTO2hbOq2RXLKm+T0Rf59V/WNt8CBOdl52YAL2Pq
pt3AW1f2iTF4IP6vLDuztdu57+2iqeGUdgsamwYU3Hi1tvJQ9hRQId994rLL
crOr4IiLLH1xejq3HX89LQtbd+WyXNBys9OuyxevM/hXBwN++ujxIxmV58rb
le2eZOuu27onDx9eX1/PFvTzbNVcPSzyLn+YL/LCbvYPr+28rPPWPfz00aeP
HxalW1SNg5VN86umLPJ6YacODsy6h06XOW3TZea8TPi6t8xpTsucwr9gmVNc
5lTWse42lTFmOp1m+RyGyhcA2Ffr0mWA0LsNjJIV1i3acm4d7RGQul6UcMhZ
s8wEw7MYwyfZ9bpcrDNnK7hmcB7VPnNbAHEBY8KO4RYWGSDIZlcrFPNF2zhn
YFsdjUzDwXx4ZbONzWuYusnKzbZtrqyfdA7jWngUxoCLugPoZLztbp8t22bD
X+GUs4M7shvbrvD1LYAIrqGDmw0TNF2zaCqa1W8NtpV3YQcb2+X0R+kM0A2b
V4Ag3bptdqu1HwFGg1FzOh43wa+vYImOto84Y9tNWTdVs9pPaFA89p1z8MS6
uTYwe17n1f5nm7kdQHTTFLZyMz6tTVkUcAPNb5CAtE3BOGDMhV88vQMgfPXN
JQ1+fuHsQtcAgIW/kAgeI8FBsC0I9fFJWy/a/Rb+OskW67yubWUAta6thSVf
N/BzsW1gZy6D42jluMOXgES1W+Jp6J0EEpM95zHpuGGKaFJcNuASA7Pm18su
AwqQ1XZhncvbPZ0E7AwwKh6Wz3lu8QQdLg+oNUAJEB92Mt8rIpmmQ6LTwV4I
h/FU6gIe8edEDwJa57CBWXbKwJvAw4A2r4FWIrITvBC54LuwMGQQeJVaXAPM
0Jl4fQqLFiYjYMH0zipUXdYifQOsI5zuLJzti+YasKmdhAOSh7PxIygRZd1u
CXe9RNzG9cg9pVsCC8c//QsG/trA3byysNHzGlawwNf2wC4IQ/mt1v5jV8Li
LE6xzuHW2Z8AOAizud03dUGD1hZxPpxM7wjHkWaWXTYbHC/fwF13vEDYBU3g
EGhAYKpdgVR9mp3yLc4XCG9i4wCW9qpcWCS6eQZkE2aycB1W6y6rmy5Dkog7
gnXxvcSllm1WNYxrEzPfARIt6bD8YLCAfA6kB95q5vilpR0uKgQq8Ibziywv
ihYWMckAOReASRWArM4cbAbWX69AgGhgYHwLlwzv6IyzjMhPicfcwCSIGws6
KAU37GzBE+p6aIKyfm08EcOljQ0eQYmBcJ3z7ufWb4nBh6DpFEf41sKAe7pp
LHWUP9tiYpRw5HDA1/A/vBqVBbpewjOwRTx2wvaGUUPo/dYukOPo88Qu9gYJ
v/DHks6x2cEK+Moi/2oBp34BgIwCSPEDOA3ezRRIMp3AiA8TqD9BmI4ft0Jk
fretmpyoOgpFBDNAr9WqtSu+yXowfRgbhTECF5jKDpAxPi63d53deNgBwJhQ
IDQ8yPy7yCcMsCIeqJBBNh+CQbJtk8zhV+dXQA/NkPdbYU95RcSuFprlL2zp
GHb8ivOwUF5He0VKDIcQrqtRCMA9bxyjT5NtENXwsKZ+JY2y8eUen0qoaZNc
WqJfTLlBIGoBcYM4oEgQxvWywYB/pM8JU09JvBE440HskAQgqymQngfqR4go
zxGRwBPbbJu2EwC9tnYblnF8vW5OmOvDjOYYxYsTlWjsbCiFLcsaoH80KnMd
MR0qNyg1VQ5Jn3AdxGSW3I4KuG6A5yTuqBR3ZN68+fOz52cvf7j45vy7v371
7OX57PGj2ePHv/v9w89+/4fP/viHP8zg/797/PjTd+8mOtTK1nDUQFntYl2X
/9gRrGkuXT89RhtLhKWr0pVyX67ytmxA/FZhD0AKUj3oRK9T6ZDpDo2Xlxtk
FywIIsmNQQ5su0IMI/FrCCK8D8geVjtYH2AqrbAlwl83fFGUXSX4YPyB4UaG
qILiLryDek/JEsXWtiDywvmvbbV1LBwIuYnXC7Boqpxv/BxOBnjipsEHCaaL
vIJBQJJZInJ3TMTXJTA0kSPgqAFHLlFWgIM4f/7q6wxhhztdgRC6dUTW9asm
lmrhhjFVkoucFwQJIQkeNcxBAZ8ZNI77cl4B3cVjfPHq1QVphSrUk167AU7B
fx6/fHF6fjLJvhUh/ydbmPjxyx2pH53s7z9+OD+LZcbjb08v/+OH5zCAaOOg
mSIvxkPx3wB7RsoA6/rW5gh1ujnHFxffnggF9dfJ7TabHPmdM4RyROYaIFgK
PLyXXk3IgVCADktPItUFpubEquCZPkyOW+PLxUBrHJkZULiFgwQYAxmOJDc8
E2RcCzzJizGcLV1E3yoUyyp7hdSEuDMQ0IqWQ1cLNIlyI2q06mC4Y9lEAXJp
9ubNpSU9IfvD7DGu68/ff332hy/++Nm7dzP40f8RNJXVjpXPhNmgiAW/toy9
sBGjRoyAZXA0VQNboMuLXKDD+YBUOH4J1gA6DiId7KjaxSQj2QpiYR4rVNEm
/jjcRFB/CLUtsKxmP4rGBklFJ5ybtkMLCCsklCBusxD9D+65LDbwcABSuQKA
x+dEvC5D0aEloogbVY3cts4TfeLRc+S3QKrZ8oBKy5hSgu8YkUxbWpsFesAS
3U8dL3QNWDFHAua3iaLVKGLhxMQnQIAh0k0IdZ3vExruSZ+gA0xMDBMWu2el
mdWrY9C9Utya/Q4Pxp/LCXEOFiVgbkd3Ir7IPIQO8OaNHNgWfoK3b7geSNIB
PUBPXtj8SyLDLDaAGGKrShUZVKir0qHURCq1K51qRkwK8Xbo0SMMCsvKOUq3
lrRHwH+cbNu3KdI1ZEKUE8OviOyAIA0zwKV3Bi0Y8PRyV3lEFFsG6VegEBH4
KsD5DrZLV41YQaxAo6YfIBahsflaNb5dCxSHNapUFukS0reEf9BjdV9CivV1
JJeGhV3Rx2CL+8OiGSIgzOIHQ4ZF40+8IYIvDFn0jChTCNVYtVJilupS/SEK
YhPLbF623RqlQFoHMMyJIemkAY54gHmR9NokTJkuEj5Dwm6uEnuk5+IaIr0Z
IAe0mFQfUaxQawRU6fZbq9AfB6tIdahtgsiOuMKSgzBBQcnExgZqputoL2Vl
V5bkjdYiAQBKsPcLN37hsjoXLQ4HJaK622T5hjQwlKOi80NFiCU4QNNlWYnW
bJa7esEIMXoD8+IK9VCACdsdYGMx8UZylhhHIv5goo0LI1ephHYgyvtBWHrj
nHVBl5M9G9lzIurzNSnbyPzDNwbJC2Abncd+Mo42IHq6hDb+FsT335LUjSdf
CmX8LUrxv2W1umhIQYF/gxLsOm/oEH4CB2k9dyYWcUhsRRah8rUKgTQSIjoS
hkAZzpgfOGOeE1aXdnEzRoI6BmTREZsu2ZqhTEUwDTBVvjBkJGEjMQqnpJEI
6xD+zhKxivt8qmx+wh3pSbk1mRyio8q7lPqcJ/oVbLhmaqCcUi7L4W2JSVlW
7iYBqM6brWIigLQNtdJK1gr6Wc9oKNYDING2Wp6YorEuMATk0sgwa5Hh8SXE
C+XPDMk+SgI8RSGCUwQ9LMhfwRBM74gWyWcZSxIlGvCK3YIwJYKNsnMTq0uK
YE9gsif/2IHW+s78CVAmvFY6gfIGnREKZa+pITa5PuVQyYVNJmVdAKEqdnkF
Q9ONA+A28y5XaWoBZw/4Y1vmxiRU8XwgrMxm/eWgF8Sy5CuzwLipd2OWZUPx
k+7NMl+UVdnhycTAAaIEzKK5Zh6m63WfwMhiRyJMJQsaIvtrMYvrMmMN7E/w
0oWzu6Kp9xsxDqNfsF6hfRuepQ1WSIdBL3RoVUlEP1Q8vZ0n2+pIX9J7MDZJ
KKB6hJ9wBqIGNGiz7KxY1Anjs6W9hsUp3n9JP9EaYKd2i3SvhssLIy9Q3anD
uKwwEvouUWqi53gmJJ21vc7EkZEdb/LXIgFvJkz4EN9FOv0EuTrCkpxO9Ddu
fcveoEm2q3HTaDZDwU4olnfl8LEvgUcV9BdaGZoDNBm2Nob9M3NKvl6xWE2C
gA9f7mrv3WCd1aFhGREdD/XV2UVgsHwVeHkiA4GA3bAxwqgxVXg22bwZQHj7
SPgkl/M+WD8IUv5hvNPimMnWNkfx+kslmCaR/VUAC2RokoGaCjiPIhORKTWd
sFto3vxkyUqlKjg6DoXH0hnNzLf4ID1HFrfkSTFyMkPE078mRabN0RpBQho/
wCKyqG5Gfs+Emlb5HtZ17CU3eVaNcwBpBG4tIr8HjZBZum+gZnd80LRJ03tH
bZi0I9DwvyeFS64Fa5ck9whEvIHSBYuS7sksR4ToA8aPbsxZAARFMcF7QQL6
AJ7/85//zPLcXa3Mg+mHfx6Yt8rrs9Psl37ewiiZX86D/s/xQh8c+OmBjPK2
9wtereGbva37n976Uc74+N9mvc/b7Ft/jm/7P10SBkSjpNMB2ozs4n1r6cNl
CRzj7nD54M/be8IXwD/g+tlv4Iqv2nwzDdeCIiK+OnrGP2Rkb5nnDm5yTCv5
Xk67Zsr3Lb6IdJ0iynP0zpjTggyE6Hy2wYwnVzYhvLEylND3YF1mqRHUhc4x
dQSRkESSQJ5x5OtIPlcO+CTcw3FiTUaEa9Y5RBpT9UFpLWxiGtOvw3QV+XZZ
MaUOEQJ1SvBNIPjiAFZy0bTlqkSWp3SDFQiUKRa2RjEseOGQxi53LVH/hEKZ
ocDdk1GJhymAxBZUCbnUFafPsDAU7FS/ToJ2w+cwQbvLJY5fSgnaGIzwFlyO
weIgQfugtdwPXD74c18ELeDL0w9Yy/0zwBHWNf7v7Db44nnXg4gBDljX+/DF
8667rOV+4PLBn4/FACkob4T5odyYM/OKGFdgPgOeQ9yOJVS1oJPkaskwrdFj
bHcUkRo94zGnEkbqZhkac73eAsouzZtyNmKepKGh4YYEZzQ1iJCMgUMiQy+a
XVXAxG5nxUMl7zS18aOlMjUwMzKHUmyNd1qpdiFW7i76hVzOrLZQoKIJvsFm
zjw6tldU5WvZwKJpXlOMH6ut8fp+nczlFxILkAXiJf2/JxZEK07DF6e3Wsu/
GbH412UugC/xkv5F8OVp+OLprdbyb4YvfeaCBkWhqiMsRsxnYxwAmQRH13R2
qMwgq/nB3fSucJ7BmyTlk7EMtYzMorMRLTekLOTzkmK9MMhVjenetdIEsT+E
2QnV1tFnmYatmshJWKLFLTYGqZNQwp9lkMBMksWOeaaHK5llT9lPF7yIqJFt
cFJmyUt4tGmdSR0pK3bqxrx6CXC1LfreOlaCQ5wPRwyqLct8e3oWTyY/c+hP
Rxqha5bdNdpTw5fEI+cWAwAb5NKR28+hiRo4b7c4YXeOEp9LbxQ1JnaJsOuF
ua5EiKPYkoRUDbRolzEPxxOfk32VbH2w1Ws+F8NRmVH0gHeVAOCAM+fzqnTr
OF6T2HbDjsrFwJI7CNAr78et4xFl4NYxH+jWyQ65dXRGw54c0o6TkA74Mvhy
Rozagn7ivytwzID4gN6wl2Us+3kfw0Q3rSZeWNIanp7ngMkGQ6NsfbJoCjJO
AgrNKLdFc4+atqRghMgz4iOC2OoQhwZIXB+Gr9VXTXVlDfkD4L5ixFbPEDoX
D32EYEm+RJrj4e+269C7LIE5aMwh90YY5Ikxj2fZGQreDRDM7bpcaIgleU2j
UACSowFfUgNTn4RN2LpBKTnJzQg463zsXzgTJYDHHBcWghCFWFJ8+QaOCcdd
HFiuUxeoDtHsOrjjuMFgPouwRKVhOHcK09vmCw7gJvvMwdVTEJgPMYP1xNQl
MnY5n4Sg2MQRvy45xXzEBcRX4D8lGoAmHLvvsfpi9FjIgs9Sv/0JsxlWeHJq
HVTIR4b/vr1NLI7sdBC6YfKhz0PjtShiT8YLfIFVJfg1jg/2EenhMkuCQEe0
oP6kSyjVgaWxFjbX8MMheSD3oRC5emU4qNvnmcgMfS+uD16KApsD6dOLMN8L
NAHtftpzZDV6pxYYPpGPpTAwnK5JPSRyeF0CBihz5ETJsHpmSadbGB6oF9/y
NALpR7J5Ri6QBFFvRXmYC5uh3MJbO3S/ELAPm8QYHdDR67KWw2HMjq3JuWyF
wcBxmy4lyM52Lr5hs+ySAuxZrlgaDokPO+NkpWv1Du2tZmBQVhLyZlqKn/ka
aaCXcGC+RY4QDLqwerQn4sCl+JZrSQHj1yl3zYrp2Cx3GGvK1xmDK9CXq/l0
IgLxfitMyKDorKLEWEIJ8s/j8zUH4n05JYeNI6MuWWS/GFASn3tmF41G9mwr
IGiYMBelF/HdwDzGnJPKGGAeA3LiQJLniMLH2cvvvnt+9mrqun2FvgDBesqE
ksgeWAeRBqLaGjTJEgGMtqtzEs4iH5+/VrI2HFBi8BLPKMf7UwYdLKgJkjii
no8tdzOTRkZPNEWUpQ+ggQWGRLrdhm53tL5FgwIjXgFau4bexFjNHGXnRJ5n
hGkoELzK6t1mjtGKwBUrAbA4F1xT7XzG0I9pVGMaESQ02ifHrAE5AI3nZQGH
tmCvfMVYUxuf4niFiObWOISPnnTpUYoQpLe8kFwwZOMYFQrQJwORZuEA8lQ2
MJyLi28nNESzWOxahk8S4SUxHeTKQYpsNEWFArcIyAw9Cg5RXoakV+JQ5HG6
zU2G8cvB0YVOjzhklfxWPsiANQYKbeVj5J3akqAcw4ghPjEcjSHB+Rpk2jWv
QXz1ccF4HwuJc0BS0cP9QPHRq9SLxefIEM9CksOjIeNFJbIaIQgKkYVdtZbk
Dw4n9+cYqQWxtsBb4sh2+No0sYj9CeIpUnklYriGCoDPXKPdOUTDoMOMp2Ym
AgY83r9m/ghJYEJOuqfj52S9JG8pxKBxXmFQVOLQxKCHrABjQVAHpWbpxyga
uj68eplNJEUiRx45JxwTuKALA7QwLyQ9ioj0dN1sx442YhgSk1I3qs9w4Cft
i7QSwp9ePtdwkyFLL2wxVedAt8wp44T2RGdF0RFKwumGvkIVllUhz2VgDzyf
xioWLaJW0VzXEtXazCNLg1BeE9JgsmInmXRVteOYnNYHfnE0kaM46NPscge3
ec9R5MqDWVJIJRPE4mWjwV4ayR+i64COEL+Hc141+EhIBrGUVGPUZuEjy8f4
nmjtfIC4JH8rM85byd78ZpM7ED7eGUO3U4Nq8JhJRyECxFuI1JnGh5GoeONz
atNYGfaKw7w+y3ycQadJ83k8Mvkz/Gk6u+LodJDuKEQvMTNxZQMMX8z1bH8i
bU5DpBEPfPAAu6T5GUnDcpyAhWnBGFNgWQZAH/2MyRdKbGusF9FKLpTbbdGB
zuFoHnYIZ0JPtGUSanJVjrA0PRVM022Agn6LXJ2znqs9W0OinKQ4hcncMicp
TbyilRdI14CRFyYpJuDKTcmZPAyMH55dZG/e/FlvPvz51fdfn33x6Rd/fPdO
Q8O2GETXORM9d37x1fn02ay03XLKaDWV85mWW3iTTAOEOzvMHGcEPafYdqId
U54dhNzddhLy4HJ5/hboJtQJuA6ywOQMfXSWXBwes6LM8XHUJVwSIsRrMgBC
t0bCIVdxWa7QpjMHoF4nRp/UyIAoTDJqLqZuXNcrGj+LQllCfLNyNUrCH8dH
I6HRov35sBWJEeHVB21MnFv06pcHlsKXfrCQcrCEOJGYJ1KwGsreidIp/Q0L
S8nj9Q7WcsHX8QZYhKAVH8oyPEKjId4KCP1bvHnJ2ihiDkXJhPAkG+R1omGT
6WgEtt5a5dbTw3iRPDnwm0Blja+PxNuMpqyAUoy3Ja0cEcBp7Gw1YzpxzpPB
pA9xQonh+Tjuyj7OPPfoq8bF97o2fkWxMIdCYWAJsv9bxMJokNct1vLvFwvT
x5cLoTG3xJZ/+VgY2Y+fn8nXSBjnjfiCBFGDYf4/joV5O+ADt0aTaC2/FC6D
UX4RvoyMEuHLK+VdfXx5/yjJdCHq905ruR+4fPDn/vClz4t/Ib4c/tzPPbrL
nb55lIi+xLg0oC93WEvApTus5VdJX/rhEI/RvjGMg2hqS5aPbSyKUpCDRDlg
3NuxZEOfqK4cihNQvbt2XCPvuZ7FKnPdeI3bcN6vaEJiRRUKEhIY0RVEFh6U
/llAjf6d/s4vG335SzL1sQVQ9K+iKGOJ19vTgmMkn2OJO81GUVOPaM7OsiYN
24jhhkbHg9pSxsbcJHTRoeXMSekQ9D2TzhS2cFhVYduqT4bi9JtFoxqhOY7r
zrAjwmVHfJeeHp2IEoKejD4DehriKkUk76lFkS5j+tlC6JGSUbxUP6IfLcvW
dbdY6amsNDkj9S1GahGpRASRY1RE4NBQLSBbwfnFiUEbiDd1ZxizzyGjazSq
DjxdkxHt7NR4nUfUoex0BGSTWGHKng5Vpv9SUcbnj/7xXyrK+OdXpKKMwOFB
7++74cvbA/+/EV9iRUWm5HsZ1nQLfIkVFf/b05vWcj9w+eDPx1NRnt5Z6DwE
lz4Uxr7pjTJyRoOTGPlmMMoAX/rYEb65YZTRmU8H3zzNbljL/cDlgz8fD19O
PyK+vHeUW+HLLUY5iC93GmV0LSm+vHeU+4HLB3/uWaVN5ak7IsyhHd3PPfoF
9GV0lDvTlwNruSN9Gfn8uunLULr+RfTlVp/74dPvlV9uOcp75Jdbr+VG+eVW
n1+P/NI3gXw6bgLpqfKRCeTrnpc7jXyOgyrF1YzaP3ukJxkVeKMo1CiY4Bhd
4iBYUtXZKKJMAh29f5+e4wVRTIfXfEnV5eBhwHr47SQuSXU4MKIXmYTK6rPv
Lk0/YunNmz+/xH8E53azzkv4T9dtsfhsslNcxuHqo2a0+mjqqJ+gmYFq00w3
WOl3ZU0aSJ5ELFP0ElWXzTnQRwJiZsKi0XVNcVqSY+mfjmOUvscXJ0Z8rRwJ
QQWyZQGqH7qJlFMKr/6Vo4+8ozbHKDtarRQboAEcGqSMjBx84zbj4C84Ph/H
LqaTpvU1TBap8YsjfULUcD+mEcFQch3BF/t5WxbZxQ4eWGR/s/s4TAKO9cXF
355TZMPjzx+9e0dBlLZFT2yEnrMBPowiMddaOIS670fHKSzN+9c91JJwlcTL
fRYCFf6qAWCvBuV/HAaK1hijHo/YMz+dSTkJf5R4DV/F0Q+lG7fCBTMOB+aF
pfr5FE/ft3ozsjBGS5/QQX8qeo4h2cyMr1amGCw3WMx8OSB13BM5ik9wuPqJ
kfVFu8gIeQ4U/IjtaPSqWtHETEbfja03O0+LdmM2EcBAQjo9aHqvahiDZvio
1Tb8NDEUY1ouI/BilBBFk/sNCB0RVOgbufNaKoyZ+T4L9beiumBbLH9cdyF+
gSeSOHQsueeLhNHEOt//Fdvgnf1Fd7dp6FMfZuvRf93JNhitQBHjgfx9e9vg
HdZyP3D54M/H0N0Vfh/f1jMGvbvbesZO8rDuzlcy/kb3e3CU+1jL/cDlgz8f
A18YovcXvvCvZevh3X24reeOa/m3s/UM+PYv40cjn/u5R7/gTo+t5e705eOt
5V7gcrfPx9LdSQMdUd57+kqsvYefQNNllzA5EEnJffbyBcd5f4baELcOEWc6
lXr15b9BRuwnuKCQLhliVMgHh/dKACrolFaK+jt2D3NN6+t/Y9y7JHhjn6fB
yGUXaXS6GIOq2yD9EivVl1c2yqZCwZcrEXjtnPaC+lJSoZpSp978Ji7wb8by
qvK4UScA7eL787+fnv2Pi9PLy2AfiEaZxi9I9LwvS+2tJVLiYGBJSBaQhvNz
1iBlkPusGi5fQG3GYGiMZFlmcMShLyTWY69FZkcIU+8YX/dW8+QmnKRAOV+k
VWL2GGeAaSVA1NgxOIHbTPTKYVAPAc5Q8fnO67zATD8sMQB60OnFq7MXp4w1
ekzSqQZDsTnnbL+NmgZgJjnXs8COiFiZgnSbtV28dkYK21JwTdqHRSGTNoFC
GNAopMBILao2Gyu2ij9xSgpBYEJx5R7eXMC4NzTDSFOwKR+/sHYDiFcWPAqH
3aQrPdQVwFdm4LzLQwnHxxpjgwoo9iCosBUrHk5OqJq22eF8j5P3WC007/e6
CVqsybMj3M9mG5dPOOqlyzNmMSAcaNdxJqkG4HP64MJiMhZj14kEjNTmCMFO
hcUPTTBJ8CDJoqTBMj+C/Mb1JxL4mQh+XJ1DlpjWEZcmmoW2C7BZf3VUXdtH
1FAUUDSEGRtiCMOPovB+H6a5uywaWOANgtftJK/3CYG3kwJllJd8wWLGfag+
70dey/3A5YM/9yeQnitm/0Jseb/gpXCJVtz/5gZDQP+M3g5+uo0Dp6/TPMCG
ycwO/DfnzBNuHOU+1nI/cLnb52MJpJHcMyKW+pDFMuV9KJde+j6RQ8LoWXRC
cuMoxphrSWYs1wkKT2jh4ZDwrI2mfLVi6UNIhkrT7mquHEElcpAp+85MUXmN
QcnJ4HbBlOql7bCcB4tO6nkZZSAWsy9VbF2sGRT8Ilp7MdeYG1dyZ40ehNQ4
S7sqC010D2JEKPlitMkXtfaIpFfs7uEby4VdFRYLIlEtFMmPD11afTFnEfyN
MPyJl66EI7N85b7MtJULDyVnQbngVeXPyoSzooo3NQuE8dHBqcmc3qpMYj0X
02JPCM2BRnMqrU8ZjLApqitQSy3+tJwICUNhdcY7BbiTIvUewhBZKtFxePYT
9keKodz4SdMjoTHpkLHi3aoveomqA6KX7xUj5R+6qNy1VmFJk1fJPxXKLsX1
fvyWwgHHBepw6UkDt56ONNrIkLPZb9PssKfBIMKuASZWop1F+4nvV2i+xNca
W1dihRjqxRV1waVSO74oh0jeFKEvKdQTgFw9pQz+ItRHcidUQwx74+po1mAn
Pet8PXOqZKBSG/1GNTWw3k4d1ZAIDVuwM7zue5Y9K53vmnsaVuz7oWfHz04v
TtRnhSostnZVQJXUOIvJDgENDuQUtap1CZSEqlRMMhiAzzzvd8i5tbbg7KK1
3ACJlJ1NU69cZw7ADKvpaNW9VDtA9edIehbfqBokI5t+Q2NC1bIOzaD9t2ns
OsWtH70ApLDtEY179A0lvx5R9T9YqtaniGYwOhboeOhulGIVvuKeNheUFIp1
0k6T2nSNnTRQZfTOMcFDJUnwMYDBL0VRFdCTy2QE5OuNyBWgGF5xM+9oCdo8
min6XRWI0adQDvyBz/BGKRCL0fIeo8feK+aoIDMul7wde+tP+C2fcsay1KGX
E2Hq7R1n9j88mPal9/8Z9jyS+sQvH1RBEjnRA61p+Yf3zHw1nPlBOvPd9hwL
qTdAm68RPvTf+rs98HIyxnuh/UHoqWLnNp92zbapmtX+PeImkEiUMqlcHJdL
Ge9ZeXpTNRWJffGFxKT7lLY3bENtIF/dqEvrvHR2K3Ukz6VfJXN5tXTFdgeq
VkNVhdAWVSQ9IKO5JiSyGKqWqgE4UV8+7YspTS+ZUWqxWm9q82IkLi2AxNd5
kN6JLJWGRo1UDzXuvBmNjvZEkzSVq4lprlD88mIvNagMmVta8TVtck42mSjj
iLK6QulDZVrS5q9fi5XpLsoDQu+lGB1IeVjZicRDbIE6eghJ4VDkPcf5yXDb
cT0loxIWgTuRvUIJei3uWOcb2+s1ikwrqtRlpBEbbvp4fkJ886b541k0FIiP
3mj5ZpqQay9ZNLkleMPVuRyoHWRJT/vgadPk3tbYmjnsIcnVjHyXMymmRA2b
k1vF9uUR8LP0+QNu9zza7nlkWjP4a+hcx+Vy5QIkQMJqgX6rqEehtEOVJqmb
nuViToMSk0nfg8h50rygI+l5WgKuROJ4VN8y2I69FVT62mBLhWHmHZXAGfQq
rRstGhz1gtXeCqHhHYWozYjdcNWq3sUw3IeB7oaTzp3DSrpeUQaCs8GYo/di
INyZ/u89OMJJaPUjyXON276jlosljbi2CRU3iqKZzp9xQcU1aS9AOsbWYxyZ
E7jopeI9bBXg32wwLfLNmz/jwOTtevTo0cS3eP797DE2dvZ1wzE4qof+dUIz
M9/ierCIGChxjOwALw7ulC/lQmoRHgQ53BOqV9jr4VnWtVD5oBi203zF5vNA
Jwrb5WXFl0/bRKsKEdWJglMDSltQhUpWlbmWOFNkLXpbNWnxtmhJPdbka2ea
GwlqyLal4F9qHYwsj8wtWZwtC+CNaqUT2j2LixkS84oKEAftMq7zSUHKLcai
7UnbRteUxCQq10lnwaTlfrlOcXayBD/pvdDf3oDCjqL0TgndRBqo6IX0P4zd
vCE5vbSkJsNPIrCeR8YhYozOqiLdLFOtiBmZFl5O0pB9Q85RyYnq3GYVxpwZ
Zrl6IDfaZGbR4qJlISJJBctdXUg/dOwWuVHPY6Spp+P9VSuJT9JG9WIvZNTy
avFg8xojzSWf51H8cu5csyiJzAiX7OmTPXJKEZk+SNIgSxb6ROUHqNJ2wmKl
8oDamgZL8zGUWikvqW6KUIBVkumuQe9tAByW6HuPZSzuTMvAbeM2d9qHTWSV
eb547ZtghrX2mcAywIisF1pGIe8VZH7zRkoUvksaXS/i5kAIWhzEBFsctnMP
haWBOuzQW9tx2LnvyseWgKTGcsx+0farJcqTzrjm0CazH6XRHlWRlqL9AdiH
ilF7L69YiUP54OPkmuVY/FVyHULZfSle7+PrvYC/tgOzBponrjlzIphUOPxA
hMLihBmSlu5l5OhjBVLkAm2X3HrBcD1GlbEnWvsbyJHeMSlzPUJRBpUzenW6
pVVFD4PyWOjhqqUyRXr4LNUNC6rzRSUyEKylYjssu1BmGPRLktDYg0yH7euf
0n1GpTEJYaa2ImgKclxoGycyCAo9tKhTh9x67UwPkklUQxFYV+7g/4upPD1N
nsbsE+41YPy1B3a2bVpUnWKlIhL+gnu/jlpGZ9zn+/MvPn+Mo1JgCI8sMMXl
u90cLyb7HuIDRMJPEvCPdp5d7Nxah3uEoUTMeM5rQswF5XbgH3iKgKSpBn5x
Q7N5DREpdSSmaKUfC6OMzvSqbCSCHrg6t4u4WWpdU+aKA3peUCthN5Co6tBy
ngafS/DSgFXTWFrzmyt7NiRMUtc04r03roUOZUjHkYkyoQWeYQ3Hg7AA5kJT
YumMEdF+gA/86JgcRHW4k1acUelkqrDLfzE5QTMtaM3foUQMY1QkssbFLmES
sswLA47oDjbZ1hMFfRsjUdibIkeJ6wftu8JoLPMcmba2Vi6yf+zySqDDjkEU
pmLjDHfDGZpfOPJIwtdG5RGpCO0rQSfFVMjA4+tFJmFIB4+s7PlNsksU+K1s
iORxgyBCSwNelngcrHQTtFPVhaINyTEG4JZtH6q9CtSqc2OU3xTRaeqj/CTI
7/Pfff47vOg8KYzMJdvjLBFC9F79TW0zHpQYM6LcAr1o4Sq+rFOB+0Dv6rjV
wUvQrAeLil0ME4Nul362WE/H7nxF+/6DvLKeIBwZFLIfuapqrnTEmO9BAVvV
5c+EeQ1aVEqsVB72dbApd7ADxsedIFxJnIv5bRwylFj9EtMXP6k5XmmB/OE7
s+wHfKLboSqIUq+WwGcfZN6ZnuquljgaJDXWkQqGukkHe0UYdLl7zQWtNDJ0
sBHFHIsdGCP6GWwvS2C1pDdw0F3UfSQYV3u3IYRJyjB5ucHuEEmHJRBc3gcc
FoFIQFjCXD7sL3fBVpg9owhHApcWUDchEtZXfHIdHDxRQWxT35XkzSG/t2/w
gM1MyqWolyIEjlAvYPkFEloybxhcx3Kv2lLSc+oKhBxSTcs4EOAbu0I8TEwq
6xwL/ONIJRdgHh3HROMog0PBCEuVkalW+i+QvotS8YJPK3QbkAZn3kKeA9JP
8zm1FRU3LlNeXAMx2KEao5aSESuJhmcw5wuOr0nU/oLdt7NEqkiuG5sbFTw0
m6bR7aPuCr5VxKgQ7S824KjRBhZO9YFo21hcvrIbKg//DYYnOy4OP3Q+ZG9+
U9ED7w4IQYDkTm4os3NS/IXukLJCeb2O27YV2vNlA3Jtxc5qJFPq88SDMlFs
Ml7nhsqBez87PIK5v0rZAH9fO6QnWFy4y8msQvpW5fdVUseq2i7xHx5Geea7
dbV2jablK4nKdmX/IsABkV2UzBXEQ/2DpDbzBQuHc532C+GoGbhEKCvNbSxo
qMQ4aP6WWgtukBYQaUF8si2qvtK7JrKj+SPAhRBMSIaiGnbfqbt7zBBLbWo1
JRWkjRvoei8240dQdeDqNlwLXn6m8nrM4v4eehjM98ESPIJgLmlP5xPqtdN8
ObNSa1ougDfKwQFvUdig8PGm3/KdxU+GH5trUX0m4nywmd4MoCXcWyYL7m4g
iK9rjHjH9i2omulouLQb2vM5utZigN1rewyRbCM9kKY1gy6Sr9Y7F0WQODGw
5tispcjJXuqdfuS6P2QIw1iuBlVNdPTjFygP6oPUZ68uyPTnBoUiCbV9Pw86
s3W5DTbz1hGZZ7Vg2C4uZyU+FaRTUxwOEuR1jDRJabsXKl9yYoYGNKQlDzjV
h09pjHRKWIWJfmMarsLNoLbAcDCu+R6VuOxNMjPny9FlxanacvpRVBlh04i9
RK2r3JyT2joQtqSR7HQPbNzWjrpacGft0IPNV2IopQVeiTeZM7wJKbn1R7X3
Mgj1XtUWTiKFUFe8RV4FsUEiRwQhMHDMK3ghcEwCbmbZc038vm6CIti7Fmrb
JFud1DuQJzmivS878qX17Q3LjhuCiRV9fDs+hT0e67qpP+nM3Hq7eOSQ6Xwf
MY7VY1mL2W/U4UjovuH0i50GlwIP49gAvcbcQ4rVOS/WEM2+aEDA32sbsA5/
woCbHHsPcQMrDWzyYBEr8jAAE6PbSkc2VFM1q5U4y3uu64mY99iAvMOirPwu
sKeyyOOE/y0uTs+WrXccZ4CmOFQFqW+VtMLRGUvPlIsQCUg9dBA3FxrVCGs+
kaou+KYV/GdZG09FwwEKSdegCgA/s8VAfSQo1aNszGsD0qKarwf9DGHci5hg
uGLEQf7apg13ZA15aIHmZdNZ6P5GP0RcTU9PDLoyMEpGLEWhsrvvSbkRV4A7
RCw96joMd4LsM0IgyCw55LXnwE1xTK1lEoxfqbmr/5w3bd1KcSaihfa9moNR
SOnwApi4g2B9PVbCgmF8H9mEmZp3a03okpgM3zPswIqJLg7ZWmqZ6Im0Hcml
3IVZ0/OwnxJ3QkMjLlVOYcstjG98qlrC3uMwbLa9JqPNvMAdNXXCGUjkJDRN
mDROTKSUYECGuA4xAoNsqCMuUR4fcpNzHpx4LIL4leAEzRJVAkqjGC56UIkN
/AwdIWsJ9H3gb4wr/PiSPLqsFsGlBrnJ73Cgs6V8PXjy+qlw65JEfmaQBy1h
S3JlzVtg2Whapm5/XRvKEjGnw3dJL/FYuKSmWhRDSWWgiTwN3hfHMZoUmCXJ
arzYF15giqpkLjauxNGc/kVdMbZBw9B8sqpiVmFQRg/7qIfu/U+cSbwQE+8Z
n6QBP8KLRXfgI1An14F4AW91UG8FpmtK+adJFC4rOI48WPvMkdNGTOe9atXY
CM8Dj0/iABp/J5iZoPB5KG8dUxa0ZgBtJ+tTHEs1guOHEZNOGkvPRqWcGSgv
4ICa7Pj52YuTxHXSVW5qXV2+e0cJD3+/+A4BffaCXY2H46JDRScKc16XRUpq
aP+7Gp2JTUs8T8Ud6s4boaREr2s0cyxonQRpM9VZEi9+0GSCceQ4IMEJ6Mfa
tosspgBv3KasOXbO4JptWAyjCDw7RBNtfxa/3iy91ddE7bH43Vl2c8gkN/PN
i6uG/K5EHCim3pGM6kvPg2AV/BHw9VVTFpI3WaaNi7FX+vW6OVEXVesdtMdo
zzyR7aJ87sUx6kl4AJkvEVxn6xy7gTljnoaQqrGmTGx5LaXTqE/snO9vbsSn
PDe5HkaJbE+MxhiZ+sBEmkSE94LscbjqHostfe4IlvAz0hOtbdF4R9rpAff6
REuPSqvq2rcBpLt3oNEWGS+kBqV6v6VJNUn+ntwwCRoAVWuc4pwT/+bYw+wY
Dz0QYqIrWTSEmBioGrqvq/jKgqj0DQCVvs2X1G9SzUsLNUjbn7ZVg8Yb4/tz
SsfdHhmg+cNyIkOQpjlx89iEPfMVDxs/BZHCmZoCVFF46jjIAS2rlfCEcZuU
wreZX2HYiUCDu1EGOCa+v0WDOR0+tBZZKaAF90eUPgCRZffSolPYYbkGuHTT
NIzz3Tu6yyKHU6BnqX0hMZel2ZYLuXBx6KaXc5x256awq9W60+aJkYSmqf+6
f6736EW2RBRKYIO2a0cZ9+nghkKZ2TYvdSU20pCN27+JtZbE/HLVoKEPtYPI
2thLDvcxAr2Os6kobLyRltPTQ5gdayKxoC2BINrzlPzRcQgEmoVI4l9YJSqJ
9uIX63uv5tkC3s2pIsHAZ8SExWVHXYNNNhfrI8l1iVqy4iFIHh9nuvtukUCA
qsrWK1VxB3OLWZa9l2lkYZ9PtK8dy2nqNn/l+z9SI2OL1n2M6tQ4b4lZoWbV
RXZEMO7sEYZSHfkKF0doJqILuS7rwiEyYM8VtObutllgMLr9BDjBOVD6Uhuo
r6jhUWOAgn1SOzt/SZwUva2w0kvboQ9Roh1h4K+evTyfPX40e/z40RcPLy9m
nz569Pnss8+kOsibN2doi3XpOyDI+AsnlF5s56VXduCmVwjJqiB/Q6JUnHMe
5C1SHNLWlcHrhg3amTlnGAeChQjRCRicQr0XMQe0rftBO9plmJLOODSzE1Ls
OQXPwTaJCWM7TlXtveHYv4MmjYaS65Q/5AHN4w7pk+D6yCNTQdTUEl7H29mi
UbX0rYEp3vS46MeRsjZihEcShE4k5JVjHUOchVDUnHJRvc94MqIyPkai27PE
wGt47OSKIYqhd45pwVBCAcioSEUSt0N3i7dA+shNk2Ve+iZiJcVVfTgzeU8O
yyGN1zNwueJ8azUETcN8c7yFLU1GVlNqWendg8pbGM4Fqdy+SWjEM8m9QR4V
sZs9e9ZcRpa/GY7vDYS6qwhmbC5Fu6vkM1PjZl8rR1uSk5tsVOxTF8x8j1NR
5ohiIIr9mitKCS5q2lRL7HoQmJ1jn3jYExx5lmWjzj4fEUesaUsefITUMoS5
sq3MezTHt8sLtjUma1KEH2V1aFHWPjcIjhDveaGoa1rgdBtSe6/Fli7GbDQL
4DQ/5Xx/e1tGLilMMWIrGD2Ah+kb3gNIqO4PRk/hYcRh20jlt/5IcDK2umAr
b6m4knunmxCAg8ibbDmueQxo649PoqFwKsUT3DHKFmjK3W5BMkQkwjPnaF0Q
C3cUi0M3+e8gYkkEJM2GrIsjKdUq6dC1lESoo1crxCb4sjwUSlrbAzWCYEUE
D3bwxPcmmnqgW6elrerOBwDVYpsZkEacBKkjcTwMbNCaSAClJQnI3vjOBY/Q
B60ZLFiul82t6arOazGuu06UWJwm6emepIok4h39TN6ba0llWZF5JJphwpeb
kwUQkzBxuiKANdtOrNhSIokLcnE7QVaaMLY2Ynxy8YpkC3yHo0PG5bGeh3GQ
JCPkKxQzu0imi4yuo13iEp5JsVs4TZQd0loML8Aa1vDjp1zE+vFnIZHli9lj
TGUZqRBGkbJRGiNHhmn76AWnQinFprABLrdDgk5c6irYXH2hJyFbEoEltcJ0
AKR8bDdBIZDbyRFSEf3KKxQX+AcZDzjq95bjiOO4VZerfIx3KK2cEBLTN+S4
RuqMgrjzdKNnHqvhypEwlxjCiE6Sn1vixxzp05lKYLph9QkOzSBEN4aWkJC4
WDq12nT7rfSSF3ah26p6yMy4BldGyuXpADGJYYlEFCYQBWyzXLKXiLncAi0v
JKH8bNtmCmQ1W+Ubthqo7sdBTjAVhWfgW97PmmOE1iuSNYMT2lsFdGJaRLSo
KxLBskSKUhGJruIyk4oWIa5iTBDAchHwO1B9QN2Fm6RB8EFL0loeGSW9YLqt
qMGFaMgwegszWXWESi6KHE1PyaPGf0Mbpi9bTaJUUinBu0BTd7uSf019EV+/
TzXKKwoFZV8p5V/2wjphIr4ObCamY5znaL0guQC9ZV0rRmZvPM2z9X6LrlkW
Qt0CpIG2bMQ3mHjJcQJ1j68lGTLV25ZVfq1+Vq45wQkNJXWL5JLsodeAMlCg
AhgwD+jBMBS3Isn5Wy7Oj7QGb9I1RslRqFCzKfHAQkJZiKNmpY9vcx43wQR6
4Zpdu7BRlRq+vX5R4q3pKN3KW1EoQo5RrqYVD7c9i903TgZHYsqH4aMD6eGk
jqWCtGsYGDERHVs7eanZPUH4oXEGMVKy9rsBxBQIEnbkFXzfNymULiptxAbs
KIF3LOHO4mVJQlw9rCVGIOx7wBbGdiRvycZQS5E4J7QdVY3zUhOovh0VApUz
HyTw+XiHkL2XeGpSs4mw1ogwiOrDuQ1Ds1GUWAoQwQJNyYJUNcXI4SBoasA8
+1jLbU7l62GWnsxFcrGE3CwFfFR6UOiArnelSWrefEcpMqgFqCzL+hdRHq9o
chBQFMI+t2j08HG8vWAYpOOEHRMF7DyflxVyPSpwM04W4vjh2Ag8SH9TpBXb
W2S7HrYeUfHQ0lRyipEGrf4klWJkY2MRPh5ioo0rD0RzMOAilqNVKaB3tM1o
yBB591GqYk31LLGCYgktCdp8p2ZQzSGU4ejn94SJR6xXKmCKv4Tp+rqpiN8Z
b6tGKc6HYTIv+YkiwrvGx86PzEORZ24s9CxWKWdkIkpiJntuew7C1HyEPGDw
MNsjaADSGyKy72I2MRVINUXDFWc1qgk97IBNFblKtxyHQ1JcTzBOvCDBH9Az
7Rt1DLZYmhfUttX02s6BwdppmpgLh9i0wZWgcacYakTeMY+HWl2YA3ow+yz2
CIru7L0HSaiCGFdD9rgUQCP+H1MQOK0Z+lXY8BCHOYnbKC6a4O3+bGHZiokr
lp0UKvCyZMRzqMNrqz9NVH0DHotB3FsfqlvQEukkSdMjcTBIrT4tK3gP+slC
o4pro3I81lUDUnTFZXGIRZGdVW1RbBmU/EREmMOhnlRRxMot8CHIbOtbYiaE
wogLf6mNrRVO5SboJGAktQPKTLTg/PS70wEdeMX5nosdGWBwzXXDT4p3EvOb
ptMp6YNUiGaBUY3AkVd06cybJ0zvbPHV0RLUR4v1an60ojawptuQbeR19i1C
sQb61mwcMuznVQkH8o3F2B747XX2XUNZZusceON3Jd4NFOJfsn3s72UHUAYB
8CkcEOxzYk7rrkH3xteoPedEJwFMZzu0M2b/3VIhRJGpn63b3RX8tym0NAtK
KaDUlPaa7RpLawvc5Mz8HytzxXjzzgAA
</rfc> </rfc>
 End of changes. 88 change blocks. 
1451 lines changed or deleted 717 lines changed or added

This html diff was produced by rfcdiff 1.48.