Internet DRAFT - draft-giles-mimi-user-private-discovery
draft-giles-mimi-user-private-discovery
More Instant Messaging Interoperability (mimi) G. Hogben
Internet-Draft F. Olumofin
Intended status: Informational Google
Expires: 17 February 2024 16 August 2023
Interoperable Private Identity Discovery for E2EE Messaging
draft-giles-mimi-user-private-discovery-00
Abstract
This document specifies how users can find and communicate with each
other privately when using end-to-end encryption messaging. Users
can retrieve the key materials and message delivery endpoints of
other users without revealing their social graphs to the key material
service hosts. Users can search for phone numbers or user IDs,
either individually or in batches, using private information
retrieval (PIR). Our specification is based on the state-of-the-art
lattice-based homomorphic PIR scheme, which provides a reasonable
tradeoff between privacy and cost in a keyword-based sparse PIR
setting.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://datatracker.ietf.org/doc/giles-interop-user-private-
discovery/. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-giles-mimi-user-private-
discovery/.
Discussion of this document takes place on the mimi Working Group
mailing list (mailto:mimi@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at
https://www.ietf.org/mailman/listinfo/mimi/.
Source for this draft and an issue tracker can be found at
https://github.com/femigolu/giles-interop-user-private-discovery.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Hogben & Olumofin Expires 17 February 2024 [Page 1]
Internet-Draft E2EE Messaging Private User Discovery August 2023
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 February 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Functional Requirements . . . . . . . . . . . . . . . . . 5
2.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 5
2.3. Privacy Non-requirement . . . . . . . . . . . . . . . . . 5
3. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Key distribution . . . . . . . . . . . . . . . . . . . . 5
3.2. Resolver registration . . . . . . . . . . . . . . . . . . 7
3.3. Preferred service integrity . . . . . . . . . . . . . . . 7
3.4. Cross-service identity spoofing . . . . . . . . . . . . . 8
4. Privacy of resolver lookup queries . . . . . . . . . . . . . 9
4.1. Proposed protocols . . . . . . . . . . . . . . . . . . . 9
4.1.1. Server database setup . . . . . . . . . . . . . . . . 10
4.1.2. Client key initialization . . . . . . . . . . . . . . 11
4.1.3. Client query generation . . . . . . . . . . . . . . . 12
4.1.4. Server response computation . . . . . . . . . . . . . 12
4.1.5. Client response decryption . . . . . . . . . . . . . 13
4.2. FHE key requirements . . . . . . . . . . . . . . . . . . 13
4.3. Cost estimates . . . . . . . . . . . . . . . . . . . . . 13
4.4. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Hogben & Olumofin Expires 17 February 2024 [Page 2]
Internet-Draft E2EE Messaging Private User Discovery August 2023
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Normative References . . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Glossary of terms:
* Authoritative Name Server: Final holder of the IP addresses for a
specific domain or set of domains.
* Client: A software application running on a user's device or
computer.
* Database: A collection of records all of equal sizes (i.e., padded
as appropriate).
* Dense PIR: A type of PIR scheme that is used to retrieve
information from a database using the index or position of each
record as key. This is equivalent to the standard PIR schemes
from the literature.
* DNS: See Domain Name Service.
* Domain Name Service: A system that accepts domain names and
returns their IP addresses.
* FHE: See Fully Homomorphic Encryption.
* Fully Homomorphic Encryption: A type of encryption that allows
arithmetic operations to be performed on encrypted data without
decrypting it first.
* KDS Resolver: A service that helps clients find and download the
public keys of other users.
* KDS: See Key Distribution Server.
* Key Distribution Server: A server holding the public key material
that enables a user to securely communicate with other users.
Hogben & Olumofin Expires 17 February 2024 [Page 3]
Internet-Draft E2EE Messaging Private User Discovery August 2023
* Name Server: Stores DNS records that map a domain name to an IP
address.
* Partition: A smaller division of a shard that is used to
facilitate recursion with PIR.
* PIR: See Private Information Retrieval
* Preferred Service: A messaging service that a user has chosen as
the default.
* Private Information Retrieval: A cryptographic technique that
allows a client to query a database server without the server
being able to learn anything about the query or the record
retrieved.
* Public Key Bundle: Cryptographic key and other metadata that are
used to encrypt and decrypt messages.
* Public Key PIR: A type of PIR scheme that uses a small amount of
client storage to gain communication and computation efficiencies
over multiple queries.
* Resolver: A service that helps clients find the IP address for a
domain through recursive queries over Name Servers hierarchy.
* Shard: A subset of a large database that is divided into smaller,
more manageable pieces.
* Sparse PIR: A type of PIR scheme that is used to retrieve
information from a database of key-value pairs. This is the same
as Keyword PIR in the literature.
* Transform: A process of converting the partitions in a shard into
a format that is suitable for homomorphic encryption computations.
2. Introduction
Outline of design for message delivery bridge and key distribution
server discovery mechanisms for interoperable E2EE messaging clients.
A DNS-like resolver service stores UserID <-> service pairs that map
to key distribution and message delivery endpoints (e.g. Platform1
Bridges). Each service is responsible for an "authoritative name
server" that covers its own users and this can be replicated/cached
by other providers and retrieved by sender clients using a privacy
preserving protocol to prevent social graph leakage.
Hogben & Olumofin Expires 17 February 2024 [Page 4]
Internet-Draft E2EE Messaging Private User Discovery August 2023
2.1. Functional Requirements
For a given messaging service identity handle (Phone number or
alphanumeric UserID):
1. P0 Return receiver service ID to send message payload: can be
mapped to endpoints for message delivery and key distribution
using standard mechanism -> e.g. Platform1.org/send/
(matrix.org/send/), Platform1.org/kds (matrix.org/kds)
2. P0 Return optional default receiver service ID user preference
for a given PN/UserID (e.g. default:Platform1.org)
2.2. Privacy Requirements
1. P0 Resolver service should not learn the PN/UserID a client is
querying for (i.e. who is sending a message to who)
2. P0 Resolver service should not learn the public identity of the
querying client.
3. P0 Resolver service should not learn the exact timing of when a
message is sent
2.3. Privacy Non-requirement
Hiding service reachability. All major E2EE messaging services
already publish unACL'd reachability information without opt-out i.e.
+16501234567, reachable on Messages, Whatsapp, Telegram (not
including name or any other info). Therefore this should not be a
goal (and would not be feasible to implement).
3. Proposed solution
3.1. Key distribution
┌───────┐ ┌──────────┐ ┌────────────┐ ┌────────────────┐ ┌────┐ ┌──────┐
│P1 │ │P1 │ │P1 │ │Authoritative P2│ │P2 │ │P2 │
│ Client│ │ Front End│ │ Name Server│ │Name Server │ │ KDS│ │Client│
└───┬───┘ └────┬─────┘ └─────┬──────┘ └───────┬────────┘ └─┬──┘ └──┬───┘
│ │ │ Request P2 │ │ │
│ │ │ Name Records │ │ │
│ │ │ ────────────────────────> │ │
│ │ │ │ │ │
│ │ │ Replicate P2 │ │ │
│ │ │ Name Records │ │ │
│ │ │ <──────────────────────── │ │
│ │ │ │ │ │
Hogben & Olumofin Expires 17 February 2024 [Page 5]
Internet-Draft E2EE Messaging Private User Discovery August 2023
│ PIR Query │ │ │ │ │
│ PN/UserID │ │ │ │ │
│───────────────────> │ │ │ │
│ │ │ │ │ │
│ │ PIR Query │ │ │ │
│ │ PN/UserID │ │ │ │
│ │ ─────────────────────> │ │ │
│ │ │ │ │ │
│ ╔═════╧══════════════════════╧═══════╗ │ │ │
│ ║Supported service IDs ░║ │ │ │
│ ║ + default service ║ │ │ │
│ ╚═════╤══════════════════════╤═══════╝ │ │ │
│ │ Service IDs │ │ │ │
│ │ & default service │ │ │ │
│ │ <───────────────────── │ │ │
│ │ │ │ │ │
│ │ │ Query │ │ │
│ │ │ PN/UserID │ │ │
│ │ ─────────────────────────────────────────────────────────────────────> │
│ │ │ │ │ │
│ │ │ Return Public │ │ │
│ │ │ Key Bundle │ │ │
│ │ <───────────────────────────────────────────────────────────────────── │
│ │ │ │ │ │
│ Return Public │ │ │ │ │
│ Key Bundle │ │ │ │ │
│<─────────────────── │ │ │ │
│ │ │ │ │ │
────┐ │ │ │ │
│ Encrypt Message │ │ │ │
<───┘ │ │ │ │
│ │ │ │ │ │
│ │ Send Encrypted Message via messaging providers │ │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────>
┌───┴───┐ ┌────┴─────┐ ┌─────┴──────┐ ┌───────┴────────┐ ┌─┴──┐ ┌──┴───┐
│P1 │ │P1 │ │P1 │ │Authoritative P2│ │P2 │ │P2 │
│ Client│ │ Front End│ │ Name Server│ │Name Server │ │ KDS│ │Client│
└───────┘ └──────────┘ └────────────┘ └────────────────┘ └────┘ └──────┘
Taking Platform1 client sending to a Platform2 user as an example:
1. Platform1 name server replicates authoritative Platform2 NS
records. There will need to be a shared list of participating
services and name server endpoints.
2. Platform1 client sends key bundle request to Platform1 front end
(PIR encrypted PN/UserID)
Hogben & Olumofin Expires 17 February 2024 [Page 6]
Internet-Draft E2EE Messaging Private User Discovery August 2023
3. Platform1 FE gets supported key distribution service IDs, version
number + default service=Platform2 via PIR protocol from its own
name server.
4. Platform1 FE queries Platform2 KDS to retrieve public keys.
* 4.1 Platform1 Client first sends (query and session key) encrypted
with Platform2 public key to Platform1 FE.
* 4.2 Platform1 FE sends encrypted query to Platform2 KDS
* 4.3 Platform2 KDS decrypts query and session key, encrypts
response with session key
* 4.4 Platform2 KDS sends encrypted response to Platform1 FE
* 4.5 Platform1 FE forwards to Platform1 client
5. Platform 1 Client and Platform 2 Client exchange messages through
their respective messaging providers.
This provides E2EE interop while only disclosing to gateway service
which services a phone number is registered to. In all other
respects, gateway services learn no more information than in the non-
interop case.
3.2. Resolver registration
Each service is responsible for registering user enrollments with the
resolver.
3.3. Preferred service integrity
While the preferred service is public, the user should control its
value/integrity. As well as ensuring user control, it also prevents
spoofing attacks where an attacker A could create an account on a new
service that B does not have an account on, and then set it to B's
preferred service (see cross-service identity spoofing below).
Therefore to prevent anyone but the user modifying the default
service value, records must be signed with the user's private key and
verified by the sender against their public key. For multiple key
pairs across different services, the last key pair to sign the
default service bit must be used to change the default.
Hogben & Olumofin Expires 17 February 2024 [Page 7]
Internet-Draft E2EE Messaging Private User Discovery August 2023
┌──────┐ ┌──────────┐ ┌────────┐
│Client│ │Service UI│ │Resolver│
└──┬───┘ └────┬─────┘ └───┬────┘
│ │ Register Preferred Service + Signature│
│ │ ──────────────────────────────────────>
│ │ │
│ Query PN/UserID │
│ ─────────────────────────────────────────────────────────────────────────────────>
│ │ │
│ Return supported service IDs + default service preference + signature │
│ <─────────────────────────────────────────────────────────────────────────────────
│ │ │
│────┐ │
│ │ Verify default service pref signature │
│<───┘ │
┌──┴───┐ ┌────┴─────┐ ┌───┴────┐
│Client│ │Service UI│ │Resolver│
└──────┘ └──────────┘ └────────┘
3.4. Cross-service identity spoofing
Today, a messaging service may support one or more ways of
identifying a user including email address, phone number, or service
specific user name.
Messaging interoperability introduces a new problem that
traditionally has been resolvable at the service level: cross-service
identity spoofing, where a user on a given E2EE may or may not be
addressable at the same ID on another service due to a lack of global
uniqueness constraints across providers.
As a result, a user may be registered at multiple services with the
same handles, e.g. if Bob's email is bob@example.com
(mailto:bob@example.com) and his phone number is 555-111-2222 and he
is registered with Signal and iMessage, he would be addressable at
bob@example.com (mailto:bob@example.com):iMessage,
555-111-2222:iMessage, and 555-111-2222:Signal. In this case, the
same userId on iMessage and Signal is acceptable as the phone number
can map to only one individual who proves their identity by
validating ownership of the SIM card.
On services where a user can log in with a username _alone_, however
e.g. Threema and FooService, the challenge becomes:
* Alice messages Bob at Bob's preferred service (bob@Threema)
* Eve messages Alice impersonating Bob using bob@FooService
Hogben & Olumofin Expires 17 February 2024 [Page 8]
Internet-Draft E2EE Messaging Private User Discovery August 2023
* Alice needs some indicator or UI to know that bob@Threema isn't
bob@FooSercice and that when bob@FooService messages, it should
not be assumed that bob@FooService is bob@Threema.
Options for solving this are: 1. Storing the supported services for
a contact in Contacts and if a receipt receives a message from an
unknown sender, to treat it as spam or otherwise untrusted from the
start. 2. Requiring the fully qualified username for services that
rely on usernames only - e.g. bob@threema.com vs bob.
4. Privacy of resolver lookup queries
Resolver lookup queries leak the user's social graph - i.e. who is
communicating with whom, since the IP address of the querying client
can be tied to user identity, especially when operating over a mobile
data network. Therefore we propose to use Private Information
Retrieval (PIR) to perform the resolver queries. We have evaluated
multiple alternative schemes. The proposed solution is based on the
Public Key PIR framework by Patel et al[PIRFramework] with sharded
databases. This framework is applicable with any standard PIR scheme
such as the open source implementation here
(https://github.com/google/private-retrieval). Cost estimates
suggest this is feasible even for very large resolver databases (10
billion records).
4.1. Proposed protocols
A private information retrieval protocol enables a client holding an
index (or keyword) to retrieve the database record corresponding to
that index from a remote server. PIR schemes have communication
complexities sublinear in the database size and they provide access
privacy for clients which precludes the server from being able to
learn any information about either the query index or the record
retrieved. A standard single-server PIR scheme provides clients with
algorithms to generate a query and decrypt a response from the
server. It also provides an algorithm for the server to compute a
response.
The Public Key PIR framework [PIRFramework] can be wrapped around any
standard lattice-based PIR scheme. This framework consists of server
database setup, client key initialization, client query generation,
server response computation, and client response decryption sub-
protocols. All operations are over a set of integers with a
plaintext modulus.
Hogben & Olumofin Expires 17 February 2024 [Page 9]
Internet-Draft E2EE Messaging Private User Discovery August 2023
4.1.1. Server database setup
* *Sharding*: If the database is over 2^20 records, sub-divide it
into shards of ~1 million unique records each, which is a good
balance for privacy and costs. Performing PIR over the databases
gives stronger privacy but is more costly. Similarly, running PIR
queries over the shards is less costly but gives weaker privacy.
- Sample a hash key *K_s* for sharding.
- Using *K_s*, shard the large database of *r* records into
*⌈r/2^20⌉* shards based on the hash prefix of the
record's unique identifier.
- *N.B.* The hash key will be provided to clients to determine
the shard to query.
* *Set partitioning boundaries for each shard D*: Given a *n* key-
value pairs shard *D = {(k_1,v_1),...,(k_n,v_n)}*, then
- Compute the number of database partitions as *b = n/d_1*. Where
*d_1* is the desired size for each partition. A value of 128
for *d_1* works well.
- Sample a partitioning boundary hash key *K_1* to generate a
target partition for each shard key.
- Compute the hash *F_1(K_1,k_i)* for each record identifier
*k_i*.
- Sort the hash values alphanumerically and then divide the list
into *b* partitions *P_1,...,P_b*.
- Store the b partition boundaries beginning hash values *B_0,
..., B_b*. Note that *B_0 = 0*, and *B_b = |U|-1* where U is
the rage for *F_1(K_1,k_i)*.
- *N.B.* The partition boundaries will be provided to clients and
can be stored efficiently (e.g., ~11KB for *n* = 2^(*20*),
*d_1* = 128, *|U|* = 2^(*64*)).
* *Transform each shard*: Sample two hash keys *K_2* and *K_r* where
*K_2* will be used to generate a row vector within each partition,
and *K_r* is used to generate a representation for the transformed
database as *F(K_r,k_i)||v*.
* *N.B.* *F(K,k)* is the output value from hashing *k* with key *K*
and *||* is a concatenation.
Hogben & Olumofin Expires 17 February 2024 [Page 10]
Internet-Draft E2EE Messaging Private User Discovery August 2023
* For each partition *P_i*
- Construct a *|P_i| x d_1* Platform1 *M_i* by appending a random
row vector from the bit vector derived from
*(F_2(K_2,k||1),...,F_2(K_2,k||d_1))*.
- Construct a *|P_i|* vector *y_i* by appending *F_r(K_r,k)||v*
for each *(k,v)* in *P_i*.
- Solve for *e_i* that satisfies *M_ie_i = y_i*.
* Construct the transformed *d_1 x b* Platform1 as *E = [e_1 ...
e_b]*.
* The Platform1 *E* is the transformed Platform1 for shard *D*.
* The clients must download parameters *(K_1,K_2,K_r)* to query each
shard, plus *K_s* to inform the server of the target shard for a
query.
This protocol is completed by the server without any client
participation and before answering any client query. Note that a
shard must be re-transformed after an update. Shard transform only
takes a few minutes.
4.1.2. Client key initialization
* The client generates a per-key unique identifier (*UID*), *private
key* and *public key* using a fully homomorphic encryption (FHE)
scheme relying on hardness assumptions similar to Ring Learning
with Errors problem.
* The client persists the *UID* and *private key* into its local key
store, and uploads query-independent parameters *UID* and *public
key* to the server. These later parameters will enable the server
to perform cryptographic operations (i.e., FHE) efficiently.
* The server needs to maintain an up-to-date mapping of *UID* to
*public key* for all clients.
* Each client completes this offline initialization protocol before
running any query. It also needs to perform it periodically
(e.g., weekly or monthly) to prevent server linkability of private
queries to the user over an extended period.
* The client downloads query parameters from the server:
Hogben & Olumofin Expires 17 February 2024 [Page 11]
Internet-Draft E2EE Messaging Private User Discovery August 2023
- Sharding hash key *K_s* to inform the server of the target
shard for a query.
* Sets of parameters (*K_1,K_2,K_r,B_0, ..., B_b*) for each shard.
4.1.3. Client query generation
* The client creates a query to retrieve the value corresponding to
a database key *k* as follows:
* Select a standard PIR algorithm with server-supported
implementation as the underlying PIR scheme.
* Compute *d = F_s(K_s,k)* to identify the shard to query.
* Compute *j = F_1(K_1,k)* to learn which partition contains the
desired entry from the downloaded partition boundaries for the
shard.
* Generate *z* vector *v* of length *d_1 , ... , d_z* . Compute a
*d_1*-length random bit vector *v_1* from
*(F_2(K_2,k||1),...,F_2(K_2,k||d_1))*. Compute *v_2* as a zero bit
vector of *d_2* length with only the bit set at
*⌊j/⌈n/d_1d_2⌉⌋*. Similarly compute *v_3 ,
... , v_z*.
* Finally use the underlying PIR scheme and the private key to
encrypt the *z* vector *v.*
* Send *v, d* and the *UID* to the server.
* *N.B.* The dimension *d_z* is typically small; a size of 2 or 4
works well.
4.1.4. Server response computation
* The server retrieves the public key for the client's *UID*, and
computes the ciphertext of the value corresponding to the key of
interest for the shard *d*, as follows.
* Take the transformed shard *E* as a *d_1x ⌈n/d_1⌉*
Platform1 *E_1*, use the underlying PIR response answering
algorithm to compute *v_1.E_1*, and rearrange the resulting
*⌈n/d_1⌉* vector as a *d_2x ⌈n/d_1d_2⌉*
Platform1 *E_2*.
Hogben & Olumofin Expires 17 February 2024 [Page 12]
Internet-Draft E2EE Messaging Private User Discovery August 2023
* Next, compute *v_2.E_2*, and rearrange the resulting *⌈n/
d_1d_2⌉* vector as a *d_3x ⌈n/d_1d_2d_3⌉*
Platform1 *E_3*.
* The server similarly repeats the computation for the remaining
dimensions *v_3 ,... , v_z*.
* The end result is a ciphertext *r* of the database value
corresponding to *k*. The server sends *r* back to the client.
4.1.5. Client response decryption
* The client uses the underlying PIR response decryption algorithm
and *private key* to decrypt the response *r* as *k_r||v*. If
*F_r(K_r,k) == k_r* then returns *v* otherwise returns *null* (key
not found).
4.2. FHE key requirements
* At least 128-bit of security
- ElGamal, NIST P-224r1 curve and a 4 bytes plaintext size for
fast decryption.
- Gentry-Ramzan, used a 2048-bit modulus
- Damgaerd-Jurik, used 1160-bit primes
4.3. Cost estimates
In these estimates, we propose using shards of size ~1 million of
identifiers. For 1.28 TB (10 billion records), breaking this down
into 10,000 shards each of size 1 million records gives a cost
estimate for each query as below:
Hogben & Olumofin Expires 17 February 2024 [Page 13]
Internet-Draft E2EE Messaging Private User Discovery August 2023
+=======================================+===============+
| Parameter | Cost estimate |
+=======================================+===============+
| PIR Public Key Size Per Device, | 14 MB |
| including metadata (storage required) | |
+---------------------------------------+---------------+
| Upload Bandwidth Per Query | 14 KB |
+---------------------------------------+---------------+
| Download Bandwidth Per Query | 21 KB |
+---------------------------------------+---------------+
| Client Time Per Query | 0.1s |
+---------------------------------------+---------------+
| Server Time Per Query (Single Thread) | 0.8-1s |
+---------------------------------------+---------------+
Table 1
Note on some assumptions for feasibility:
1. Resolver queries will be cached (vs requiring a roundtrip for
every message) and asynchronous with message sending, therefore
1s latency is acceptable.
2. It is acceptable for key changes to be communicated reactively on
decrypt failure.
3. Group messaging E2EE is bootstrapped using individual users'
public keys and for V1, group state will be stored by the
initiating user's service provider. Therefore no additional
discovery mechanism is required.
4.4. Notes
5. IANA Considerations
This document has no IANA actions.
6. Normative References
[PIRFramework]
Patel, S., Seo, J. Y., and K. Yeo, "Don't be Dense:
Efficient Keyword PIR for Sparse Databases", 32nd USENIX
Security Symposium, USENIX Security 2023 , n.d..
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Hogben & Olumofin Expires 17 February 2024 [Page 14]
Internet-Draft E2EE Messaging Private User Discovery August 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Acknowledgments
The technical description of the private information retrieval
framework is based on Sarvar Patel, Joon Young Seo and Kevin Yeo's
USENIX Security '23 paper titled "Don't be Dense: Efficient Keyword
PIR for Sparse Databases "
(https://www.usenix.org/conference/usenixsecurity23/presentation/
patel).
Authors' Addresses
Giles Hogben
Google
Email: gih@google.com
Femi Olumofin
Google
Email: fgolu@google.com
Hogben & Olumofin Expires 17 February 2024 [Page 15]
