Key Consistency and DiscoveryBrave Softwarealex.davidson92@gmail.comThe Tor Projectsysrqb@torproject.orgMozillamt@lowentropy.netCloudflare101 Townsend StSan FranciscoUnited States of Americacaw@heapingbits.netInternet-DraftThis document describes the key consistency and correctness requirements of protocols such as
Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It discusses several mechanisms
and proposals for enabling user privacy in varying threat models. In concludes with discussion
of open problems in this area.Discussion VenuesDiscussion of this document takes place on the
mailing list (),
which is archived at .Source for this draft and an issue tracker can be found at
.IntroductionSeveral proposed privacy-enhancing protocols such as Privacy Pass
, Oblivious DoH , and Oblivious HTTP require
clients to obtain and use a public key for execution. For example, Privacy Pass
public keys are used by clients for validating privately issued tokens for
anonymous session resumption. Oblivious DoH and HTTP both use public keys to
encrypt messages to a particular server.User privacy in these systems depends on users receiving a key that many, if not
all, others users receive. If a user were to receive a public key that was
specific to them, or restricted to a small set of users, then use of that public
key could be used to learn targeted information about the user. Users
also need to receive the correct public key.In this document, we elaborate on these core requirements, and survey various system designs that might
be used to satisfy them. The purpose of this document is to highlight challenges in building and deploying
solutions to this problem.RequirementsThe 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 when, and only when, they
appear in all capitals, as shown here.TerminologyThis document defines the following terms:
Key Consistency and Correctness System (KCCS):
A mechanism for providing clients with a consistent view of cryptographic key material.
Reliant System:
A system that embeds one or more key consistency and correctness systems.
The KCCS's consistency model is dependent on the implementation and reliant system's threat model.Core RequirementsPrivacy-focused protocols which rely on widely shared public keys typically
require keys be consistent and correct. Informally, key consistency is the
requirement that all users of a key share the same view of the key; key
correctness is that it belongs to the intended entity and is not available to an
attacker.Some protocols depend on large sets of users with consistent keys for privacy
reasons. Specifically, all users with a consistent key represent an anonymity
set wherein each user of the key in that set is indistinguishable from the
rest. An attacker that can actively cause inconsistent views of keys can
therefore compromise user privacy.An attacker that can cause a user to use an incorrect key will likely compromise
the entire protocol, not just privacy.Reliant systems must also consider agility when trying to satisfy these requirements. A naive solution to
ensuring consistent and correct keys is to only use a single, fixed key pair for the entirety of
the system. Users can then embed this key into software or elsewhere as needed, without any additional
mechanics or controls to ensure that other users have a different key. However, this solution clearly
is not viable in practice. If the corresponding key is compromised, the system fails. Rotation must
therefore be supported, and in doing so, users need some mechanism to ensure that newly rotated
keys are consistent and correct.Operationally, servers rotating keys may likely need to accommodate
distributed system state-synchronization issues without sacrificing availability. Some systems and protocols
may choose to prioritize strong consistency over availability, but this document assumes that availability
is preferred to total consistency.Consistency and Correctness at Key AcquisitionThere are a variety of ways in which reliant systems may build key consistency and correct systems (KCCS),
ranging in operational complexity to ease-of-implementation. In this section, we survey a number of
possible solutions. The viability of each varies depending on the applicable threat model, external
dependencies, and overall reliant system's requirements.We do not include the fixed public key model from
, as this is likely not a viable solution for systems and protocols in practice. In all scenarios,
the server corresponding to the desired key is considered malicious.Direct DiscoveryIn this model, users would directly query servers for their corresponding public key, as shown below.The properties of this solution depend on external mechanisms in place to ensure consistency or
correctness. Absent any such mechanisms, servers can produce unique keys for users without detection.
External mechanism to ensure consistency here might include, though are not limited to:
Presenting a signed assertion from a trusted entity that the key is correct.
Presenting proof that the key is present in some tamper-proof log, similar to Certificate
Transparency () logs.
User communication or gossip ensuring that all users have a shared view of the key.
The precise external mechanism used here depends largely on the threat model. If there is a trusted
external log for keys, this may be a viable solution.Single Proxy DiscoveryIn this model, there exists a proxy that fetches keys from servers on behalf of multiple users, as shown
below.If this proxy is trusted, then all users which request a key from this server are assured they have
a consistent view of the server key. However, if this proxy is not trusted, operational risks may arise:
The proxy can collude with the server to give per-user keys to clients.
The proxy can give all users a key owned by the proxy, and either collude with the server to use this
key or retroactively use this key to compromise user privacy when users later make use of the key.
Mitigating these risks may require tamper-proof logs as in , or via user gossip protocols.Multi-Proxy DiscoveryIn this model, users leverage multiple, non-colluding proxies to fetch keys from servers, as shown below.These proxies are ideally spread across multiple vantage points. Examples of proxies include anonymous
systems such as Tor. Depending on how clients fetch such keys from servers, it may become
more difficult for servers to uniquely target individual users with unique keys without detection.
This is especially true as the number of users of these anonymity networks increases. However, beyond
Tor, there does not exist a special-purpose anonymity network for this purpose.Database DiscoveryIn this model, servers publish keys in an external database and clients fetch keys from the database, as shown below.The database is expected to have a table that asserts mappings between server names and keys. Examples
of such databases are as follows:
An append-only, audited table similar to that of Certificate Transparency . The log is operated and
audited in such a way that the contents of the log are consistent for all users. Any reliant system
which depends on this type of KCCS requires the log be audited or users have some other mechanism for
checking their view of the log state (gossiping). However, this type of system does not ensure proactive
security against malicious servers unless log participants actively check log proofs. This requirement
may impede deployment in practice. Experience with Certificate Transparency shows
that most implementations have chosen not to check SignedCertificateTimestamps before
using (that is, accepting as valid) a corresponding TLS certificate.
A consensus-based table whose assertions are created by a coalition of entities that periodically agree on
the correct binding of server names and key material. In this model the agreement is achieved via a consensus
protocol, but the specific consensus protocol is dependent on the implementation.
For privacy, users should either download the entire database and query it locally, or remotely query the database
using a private information retrieval (PIR) protocol. In the case where the database is downloaded locally, it
should be considered stale and re-fetch periodically. The frequency of such updates can likely be infrequent
in practice, as frequent key updates or rotations may affect privacy; see for details.
Downloading the entire database works best if there are a small number of entries, as it does not otherwise
impose bandwidth costs on each client that may be impractical.Minimum Validity PeriodsIn addition to ensuring that there is one key at any time, or a limited number keys, any system
needs to ensure that a server cannot rotate its keys too often in order to divide clients into
smaller groups based on when keys are acquired. Such considerations are already highlighted within the
Privacy Pass ecosystem, more discussion can be found at . Setting a minimum validity
period limits the ability of a server to rotate keys, but also limits the rate of key rotation.Separate Consistency VerificationThe other schemes described here all attempt to directly limit the number of keys that a client
might accept. However, by changing how keys are used, clients can impose costs on servers that
might discourage key diversity.Protocols that have distinctly separate processes for acquiring and using keys might benefit from
moving consistency checks to the usage part of the protocol. Correctness might be guaranteed
through a relatively simple process, such obtaining keys directly from a server. A separate
correctness check is then applied before keys are used.Independent VerificationAnonymous queries to verify key consistency can be used prior to use of keys. A request for the
current key (or limited set of keys) will reveal if the key that was acquired is different than the
original. If the key that was originally obtained is not included, the client can abort any use of
the key.It is important that any validation process not carry any information that might tie it to the
original key discovery process or that the system providing verification be trusted. A proxy (see
) might be sufficient for providing anonymity, though more robust anonymity
protections (see ) could provide stronger guarantees. Querying a database (see
) might provide independent verification if that database can be trusted not to
provide answers that change based on client identity.Key-Based EncryptionKey-based encryption has a client encrypt the information that it sends to a server, such as a token
or signed object generated with the server keys. This encryption uses a key derived from the key
configuration, specifically not including any form of key identifier along with the encrypted
information. If key derivation for the encryption uses a pre-image resistant function (like HKDF),
the server can only decrypt the information if it knows the key configuration. As there is no
information the server can use to identify which key was used, it is forced to perform trial
decryption if it wants to use multiple keys.These costs are only linear in terms of the number of active keys. This doesn't prevent the use of
multiple keys, it only makes their use incrementally more expensive. Trial decryption costs can be
increased by choosing a time- or memory-hard function such as to
generate keys.Encrypting this way could provide better latency properties than a separate check.Future WorkThe model in seems to be the most lightweight and easy-to-deploy mechanism for
ensuring key consistency and correctness. However, it remains unclear if there exists such an
anonymity network that can scale to the widespread adoption of and requirements of protocols like
Privacy Pass, Oblivious DoH, or Oblivious HTTP. Existing infrastructure based on technologies
like Certificate Transparency or Key Transparency may work, but there is currently no general
purpose system for transparency of opaque keys (or other application data).Security ConsiderationsThis document discusses several models that systems might use to implement public key discovery
while ensuring key consistency and correctness. It does not make any recommendations for such
models as the best model depends on differing operational requirements and threat models.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Certificate TransparencyThis document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.Informative ReferencesOblivious DNS Over HTTPSApple Inc.FastlyApple Inc.CloudflareCloudflare This document describes an extension to DNS Over HTTPS (DoH) that
allows hiding client IP addresses via proxying encrypted DNS
transactions. 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.
Privacy Pass Protocol SpecificationCloudflareLIPCloudflare This document specifies the Privacy Pass protocol. This protocol
provides anonymity-preserving authorization of clients to servers.
In particular, client re-authorization events cannot be linked to any
previous initial authorization. Privacy Pass is intended to be used
as a performant protocol in the application-layer.
Privacy Pass Architectural FrameworkLIPCloudflare This document specifies the architectural framework for constructing
secure and anonymity-preserving instantiations of the Privacy Pass
protocol. It provides recommendations on how the protocol ecosystem
should be constructed to ensure the privacy of clients, and the
security of all participating entities.
Oblivious HTTPMozillaCloudflare This document describes a system for the forwarding of encrypted HTTP
messages. This allows a client to make multiple requests of a server
without the server being able to link those requests to the client or
to identify the requests as having come from the same client.
The memory-hard Argon2 password hash and proof-of-work functionUniversity of LuxembourgUniversity of LuxembourgABDK ConsultingSJD AB This document describes the Argon2 memory-hard function for password
hashing and proof-of-work applications. We provide an implementer-
oriented description with test vectors. The purpose is to simplify
adoption of Argon2 for Internet protocols. This document is a
product of the Crypto Forum Research Group (CFRG) in the IRTF.