lonerapier.xyz

Search

SearchSearch

TLS Notary

Jul 30, 20244 min read

A primer on TLSN.

TLS provided integrity and secrecy in untrusted channels on PKE, which allowed 2 parties to communicate over the internet securely, TLSN takes it a step further. Anyone can now prove that the messages exchanged between two parties are valid.

TLSN introduces a new party called notary, analogous to CA in PKI setting. Notary attests and produce proofs of the transcript between a server and a client. Can be described by 4 properties:1

  • Provenance: verifying the server’s public key using CA chain verification.
  • Privacy: TLS (key exchange, encrypt, authenticate, decrypt) is done using mpc with notary, so that notary never observes the client/server messages in plaintext.
  • Authenticity: notary uses blind signatures to produce commitments on client’s messages so that client can’t change transcript later.
  • Non-Proprietary: transcript can be produced by any notaries, and not just trusted ones.
flowchart LR

Server<--(3) HTTP-->Prover

subgraph MPC
	direction TB
	subgraph Prover
		c
		socket
	end
	socket<--(1) MPC-->n["Notary"]
	socket--(2) MPC TLS-->c["TCP Client"]
	n--Commitment-->Prover
end

MPC["Prover"]--"(4) Selective Disclosure"-->v["Verifier"]

In other words, protocol can be divided into two phases:

  • Online phase: MPC TLS connection between notary and Prover, and communication with Server.
  • Offline phase: transcript verification by verifier

Questions

  • If the motivation is Non-repudiation, why doesn’t signatures work directly?
    • Server doesn’t sign the data, so there’s no way for client to repudiate the claim they’re making to a third party. Even if they do, Privacy isn’t guaranteed. Selective disclosure of data is important to safeguard the private contents of data returned by the server.
  • What’s the role of Notary?
    • Notary is just an additional participant in the protocol which the verifier delegates the work of secure TLS computation with the Prover.
    • responsible for Key exchange, encryption, authentication, decryption part of TLS, signs commitment to Prover’s request messages using blind signatures
    • Not necessary, if the MPC TLS protocol is run between prover and verifier.
  • Difference between notary and verifier?
    • Verifier can be anyone who wishes to verify the transcript between Server/Prover, and can be done in offline phase.
    • Notary needs to participate in online phase, where multi-party computation for TLS happens between prover and notary.
  • Bandwidth overhead for MPC?
  • Is bandwidth overhead constrained at Prover’s side or notary’s side?
  • Verifier time and constraints?
  • you’re making a wrapper on top of the APIs provided by the companies? How do you plan to play the cat-mouse game? What happens when responses change? Or request changes?

Next steps

Projects & Use cases

  • zkEmail
  • zkPassport
  • web proofs

This paves the way for countless Web3 applications: ​

  • Identity authentication
  • Resolution in prediction markets
  • Mixed Web2-Web3 loyalty and incentive program
  • Privacy-focused verifiable assets
  • Tokenising Domain
  • On-Chain Attestations of Off-Chain Activity
  • DeFi protocols with undercollateralised loans
  • Verification and claims in insurance
  • Shared electronic medical records
  • Secure, private e-commerce
  • Payment attestations for on/off ramp
  • Interoperable social media platforms
  • Verified gaming history
  • AI collaboration with zkLLM
  • Machine verification in DePIN
  • Secure digital voting
  • Encrypted mempools

https://x.com/Euler__Lagrange/status/1829064325224407061 https://x.com/richardzliang/status/1828992045844746727 https://x.com/Flynnjamm/status/1828888256035074357 https://x.com/Euler__Lagrange/status/1828969800783065203 https://x.com/sina_eth_/status/1828566424232829087 https://x.com/zkJyu/status/1828888929103417622 https://x.com/nico_mnbl/status/1829484200694571101

References

Footnotes

  1. Pluto’s: How TLSNotary Works ↩

Graph View

Backlinks