Commitments and zero-knowledge attestations over TLS 1.3: DiStefano protocol

Joint work with Sebastian Angel (University of Pennsylvania), Sofía Celi (Brave), Alex Davidson (NOVA LINCS & DI, FCT, Universidade NOVA de Lisboa), Hamed Haddadi (Brave Software & Imperial College London), Shai Levin (University of Auckland), Elizabeth Margolin (University of Pennsylvania), Gonçalo Pestana (Hashmatter), Joe Rowell (Royal Holloway, University of London), Jess Woods (University of Pennsylvania). This post was written by Brave’s Security Researcher, Sofía Celi.

Just as in DECO, DiStefano is named after the football player DiStefano, who, while being Argentinian, worked for Spain most of his professional life. It is related to the fact of using something from one place in another place (TLS data to externally attest) (Image partially AI generated).

The Transport Layer Protocol (TLS) is one of the most widespread protocols that secure data in transport over the Internet. Thanks to its widespread deployment, users are assured that their data in transport remains secure and private as the protocol (especially, in its 1.3 version) provides encrypted and authenticated channels between clients and servers on the Internet. Such channels commonly transmit trusted information about users behind clients such as

proofs of age, social security statuses, bank account information and accepted purchase information. While various applications would benefit from learning such data points, doing so raises significant privacy concerns. Exporting such information as private, anonymous credentials is challenging because it is transmitted over an encrypted and authenticated channel. Meanwhile, both legislation (such as GDPR) and standards bodies (such as W3C) have made usage of privacy-preserving data credentials a priority. Therefore, it is critical to develop methods that enable users to selectively and consensually export portions of their data. This would allow them to prove specific statements or authenticate that the data originates from a trusted source, such as a particular website, without compromising privacy.

To illustrate the problem, consider that Alice wants to prove to a service that they are over 18 (a website, for example, can request such a proof). Currently, most age verification services require users to upload identification documents containing extensive personal information, raising significant privacy concerns. If Alice chooses not to share their ID, they may be denied access to the service, even though they meet the age requirement. Meanwhile, many websites, such as company payroll systems or DMV portals, already store and serve verified birth dates. Alice could, in theory, share a screenshot of her birth date from one of these sites, but this approach has two major flaws: screenshots are easily forged, and even if their authenticity could somehow be guaranteed, they would reveal unnecessary information, such as Alice’s exact birth date, instead of simply proving that they are over 18. This situation highlights the need for a mechanism that achieves two goals: proving the authenticity of the data (ensuring it is not forged) and proving a specific statement about the data (e.g., that Alice is over 18) without disclosing additional details. Such a solution would enable both proofs of provenance and proofs of statements, which will allow users to access services without compromising their privacy and ensuring trust. These types of proofs can be useful, for example, in anti-fraud checks (and we will talk about this at the end of the post). 

In this blog post, we will explore a solution to this problem by leveraging TLS to create both proofs of provenance and proofs of statements. This approach enables users to consensually generate zero-knowledge proofs of their data, allowing them to securely access additional services while preserving their privacy.

DCTLS protocols

Designated-Commitment TLS (DCTLS) protocols, also known as three-party handshake (3PH) protocols or ZKTLS, enable modified TLS handshakes that allow specific statements about the data exchanged in a TLS channel to be securely exported to a designated verifier (a trusted party). These protocols secret-share private session data between a client and verifier, and compute the handshake and record-layer phases of TLS phases of TLS using two-party computation (2PC), a type of MPC that allows two parties to jointly compute a function while keeping their respective inputs private. Notable examples of DCTLS protocols include DECO, TLSNotary/PageSigner, TownCrier, Garble-then-Prove, and Janus (similar techniques are also used to produce zero-knowledge middleboxes for proving that client traffic adheres to corporate browsing policies, for example, and for devising multi-party TLS clients/servers).

Despite their claims of practicality, these protocols face significant barriers to wide-scale adoption.

1. Lack of TLS 1.3 Support: None of the protocols listed explicitly provide secure support for TLS 1.3, even though it became the dominant version of TLS as of December 2020. According to Cloudflare Radar, TLS 1.3 now accounts for 63% of secure network traffic, compared to only 8.7% for TLS 1.2. Support for TLS 1.3 is therefore crucial. Even when TLS 1.3 is supported, existing protocols often lack rigorous security analyses or fail to address efficiency concerns associated with implementing TLS 1.3 ciphersuites and protocol steps in maliciously-secure 2PC.

2. Security Limitations: Current security arguments lack flexibility, as they are tied to specific, static protocols, ciphersuites, and 2PC primitives. This rigidity poses risks; for instance, primitives used by DECO have already been shown to be insecure. Moreover, client privacy is frequently overlooked, with protocols exposing the server a client communicates with to the verifier: potentially revealing sensitive browsing history.

3. Deployability Challenges: No fully-featured, open-source implementation of a DCTLS protocol exists that combines strong security guarantees with interoperability for common Internet browsing tools. This absence hinders practical adoption and widespread deployment.

In order to solve all these problems, we introduce DiStefano. But, prior to explaining our protocol, let’s see how DCTLS protocols work.

DCTLS in detail

DCTLS protocols allow a Client to generate commitments to TLS session data communicated with a Server that can be sent to a designated third-party Verifier. They consist of the following phases: 1. A (Verifier-assisted) handshake phase, 2. a (Verfier-assisted) query execution phase, and 3. a commitment phase. Over TLS 1.3 (given an informal description of TLS 1.3 with 1-RTT and with certificate-based authentication), these phases look like this:

Handshake phase. In this phase (as seen below), the Server learns the same secret session parameters as in standard TLS 1.3, while the Client and the Verifier learn shares of the session parameters that only the Client would normally learn: they engage in the core TLS 1.3 protocol using a series of 2PC functionalities, hence, they secret-share session data and arrive to session secret keys that are secret-shared. 

Record Layer-Query Execution phase. At the record layer, encrypted traffic is exchanged between the Client and the Server (as seen below). The Client sends an encrypted query (e.g., an HTTPS request) to the Server with assistance from the Verifier. Since the session secret keys are secret-shared, the Client and Verifier collaboratively compute the encryption of these queries using two-party computation (2PC). Similarly, encrypted responses from the Server (e.g., an HTTPS response) can be decrypted using the same joint procedure. Note that these responses must first be committed to, as discussed in the next phase.

Record Layer-Commitment phase. After the encrypted queries are sent and encrypted responses are received, the Client commits to the session by forwarding the ciphertexts (e.g., the encrypted responses) to the Verifier (as seen in box 3 of Figure 1). In exchange, the Verifier provides the Client with its shares of the session secret keys. This allows the Client to verify the integrity of the Server’s response and, later, prove statements derived from it to the Verifier. For example, using the committed encrypted response now held by the Verifier, the Client can prove in zero-knowledge that a specific statement is true (e.g., that an HTTPS response contains a field representing age, and that the age is greater than 18).

As we can see, DCTLS protocols are straightforward: they allow a trusted third party (the Verifier) to participate in the handshake (by performing operations in 2PC), enabling the Verifier to commit to encrypted data. This data can later be used to create zero-knowledge proofs. We require this commitment for zero-knowledge proofs: the data that one intends to prove a statement about must be committed to, ensuring its immutability. However, the Verifier never learns the plaintext data unless the Client chooses to reveal it. The Verifier only holds shares of the full session secret keys, and the encrypted data cannot be decrypted unless the full session secret keys are known.

DiStefano: Decentralized Infrastructure for Sharing Trusted Encrypted Facts and Nothing More

While all DCTLS follow a similar approach, with our protocol, DiStefano, we improve upon it by:

1. Making it all work with TLS 1.3 as described in the previous section and in detail in our paper.

2. Providing a full security model: we provide a modular, standalone security framework that guarantees security in the presence of malicious adversaries.

3. Improving privacy guarantees:  In the handshake phase, when the Server sends its certificate messages to the Client, relaying those messages to the Verifier for verification would disclose the Client’s browsing history over time. This is because the Server’s certificate contains its identity, which could potentially reveal the Client’s activity. In DiStefano, we aim to prevent this. Instead, we use zero-knowledge proofs of knowledge of valid signatures (ZKPVS) for signatures generated during TLS exchanges. In this scheme, one holds a valid signature issued by your keypair, while a verifier holds a set of valid public keys, one of which corresponds to your keypair. The goal is to demonstrate that the signature is valid with respect to this set without disclosing your specific public key. This ensures that the prover’s identity remains private, preserving the Client’s privacy. For this purpose, our CDLS scheme can be used with EC-DSA signatures.

1. Making AES-GCM be a commitment scheme: To commit to the encrypted data, one could use traditional commitment schemes such as Pedersen Commitments. However, we opted to leverage the existing functionality provided by the TLS 1.3 protocol. This involves adapting AES-GCM (the algorithm supported by TLS 1.3 to encrypt data),  to act as a commitment scheme. Since AES-GCM, when used in an AEAD setting, functions as a non-committing cipher, we introduced modifications to make it committing. Specifically, this was achieved by verifying the tag in relation to the ciphertext. For a comprehensive explanation of our approach, please refer to our paper.

As such, DiStefano is a DCTLS protocol that operates securely within TLS 1.3, offering formal security guarantees and ensuring client privacy. It is also highly efficient, as demonstrated through WAN experiments evaluating its performance in practical scenarios. The results indicate that runtime increases are proportional to the latency introduced, with slight deviations due to circuit preprocessing and GCM share derivation. Circuit preprocessing adds to the runtime but is an offline, amortizable cost. The derivation of GCM shares, reflecting the multi-round trip nature of the protocol, consistently takes less than a second. Even with these factors, the total online costs remain significantly lower than typical TLS handshake timeouts, which are usually configurable between 10 and 20 seconds. Additionally, the impact of increasing latency appears sublinear, suggesting that DiStefano maintains high efficiency and practicality across a variety of browsing scenarios.

So, what else can be done? Well, DiStefano is a pretty complete protocol that gives you commitments to TLS 1.3 encrypted data, but it does not yet give you the zero-knowledge proofs over that data. Let’s explore that now.

Zero-knowledge proofs

The data transmitted over TLS can take various forms, depending on the application. Common formats include HTML for web pages and JSON for APIs, but other formats like XML, binary data, or proprietary protocols can also be transmitted securely over TLS. This means that the data we aim to prove statements about is often structured in these formats. For example, let’s examine a JSON blob containing an age field:

{
  "name": "DiStefano Protocol",
  "version": "1.0",
  "description": "A DCTLS protocol over TLS 1.3.",
  "age": 2,
  "features": {
    "security": "Proven fully secure",
    "privacy": "Maintains client privacy",
    "efficiency": "Highly efficient"
  },
  "performance": {
    "runtimeImpact": "Proportional to latency",
    "gcmShareDerivationTime": "Less than a second",
    "totalOnlineCost": "Below typical TLS handshake timeout"
  },
  "latencyImpact": "Sublinear"
}

If this data is transmitted over TLS 1.3 as a Server’s response to a Client’s request, DiStefano can be used to commit to the encrypted data. Once committed, if we want to prove that the field “age” has a value greater than 1 (a proof of a statement), we need to demonstrate the following:

1. The data conforms to the JSON context-free grammar: JSON is defined by a formal context-free grammar specifying rules for objects, arrays, strings, numbers, and other components. For example, an object must consist of key-value pairs enclosed in braces {} and separated by commas. Verifying adherence to this grammar ensures the data is valid JSON.

2. The field “age” exists at the top level: In the JSON grammar, keys must be strings, and the presence of the “age” key as a direct child of the root object needs to be validated to ensure it is not nested within another object or array.

3. The value associated with “age” matches the grammar rule for integers: JSON defines numeric values, including integers and floats. We need to prove that the value of “age” satisfies the grammar rule for integers.

4. The value of “age” satisfies a semantic constraint: While grammars handle structural validity, proving that the value of “age” is greater than 1 requires an additional semantic check beyond the grammar rules.

We are actively working on research to address these challenges. For point 1, for example, we build on the outstanding Reef protocol, extending it to handle context-free grammars. This enables proving that committed JSON data either matches or does not match a given regular expression. For points 3 and 4, we are designing custom zero-knowledge proof systems that allow generating proofs over AES-GCM and ChaCha20-Poly1305, the two primary ciphersuites supported by TLS 1.3. Expect blog posts and papers on this soon!

Why is this useful?

Earlier in this blog post, we discussed how leveraging TLS 1.3 encrypted data to create proofs of provenance and proofs of statements can be valuable for allowing users to access additional services. However, this is just one example of its potential.

These types of proofs can also be useful in anti-fraud checks. For instance, a user could prove in zero-knowledge that they have an account with one of several authorized banks (without revealing which bank it is). This kind of proof could serve as a signal that the user is not a bot, enabling them to access services while preserving their privacy and preventing them from being falsely flagged as a bot. One can also use these proofs to verify “real” events by producing statements that confirm the origin and trustworthiness of data, helping to demonstrate that it was not generated by Artificial Intelligence (AI). However, it is important to note that DCTLS protocols could become actively harmful tools for monitoring or censoring client traffic in certain applications, especially in automated systems without human involvement. We would like to emphasize that deployment of tools such as DiStefano must be considered carefully in such contexts.

Interested in trying our protocol?

If you are interested in trying our protocol, we implemented a full prototype of DiStefano in C++. It is built directly over BoringSSL, so it can be integrated easily over Chromium-based browsers. In fact, one of our future works is integrating this implementation directly on the Brave browser so we could leverage this protocol to detect fraud behaviour (detect bots, for example) and attest humanity without degrading usability.

If you are further interested in reading our research, you can read our paper. Or you can find us at the NDSS2025 Symposium, where the paper will be presented.