Key Transparency (KEYTRANS)

Description

While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attacks, such as a service provider distributing malicious public keys to selectively intercept communication.

While being vulnerable to active attacks could be acceptable in a scenario where active attacks are otherwise hard to launch (for example, in peer-to-peer communication over the Internet), most messaging applications are not designed this way. Instead, they're designed to pass all messages through servers controlled by the service provider. This allows the service provider to trivially distribute fake public keys and then eavesdrop or impersonate a user with minimal risk of detection, despite the use of end-to-end encryption.

Key Transparency (KT) is a safe, publicly-auditable way to distribute cryptographically-sensitive data like public keys. It builds on top of previous protocols, primarily Certificate Transparency, in ways that make it more suitable for the use-case of end-to-end encryption. Importantly, users can efficiently search a KT server for only the entries that are relevant to them and check that the server responded honestly. KT servers can also better preserve their users' privacy, by controlling when or if one user is allowed to learn another user's data.

This effort aims to standardize a common protocol for Key Transparency that 1.) works for a large range of use-cases, 2.) provides clean security guarantees, 3.) is able to be thoroughly studied by security researchers, and 4.) has trustworthy open source implementations.

Required Details

• Status: Not WG Forming
• Responsible AD: Roman Danyliw
• BOF proponents:
• Brendan McMillion <brendanmcmillion@gmail.com>
• Antonio Marcedone, Zoom <antonio.marcedone@zoom.us>
• Kevin Lewi, Meta <klewi@meta.com>
• Esha Ghosh, Microsoft <Esha.Ghosh@microsoft.com>
• BOF chairs: TBD
• Number of people expected to attend: 100
• Length of session (1 or 2 hours): 2 hours
• Conflicts (whole Areas and/or WGs)
• Chair Conflicts: SEC Area
• Technology Overlap: MLS, MIMI
• Key Participant Conflict: TBD

Information for IAB/IESG

Protocols that already exist in this space:

• Certificate Transparency [RFC6962]
• Keybase [https://book.keybase.io/docs/server]
• CONIKS: Identified need for Key Transparency [https://eprint.iacr.org/2014/1004]
• SEEMless: Built on CONIKS to support faster updates [https://eprint.iacr.org/2018/607]
• Merkle^2: Developed more efficient auditing protocols [https://eprint.iacr.org/2021/453]

Open source projects implementing this work:

• https://github.com/google/keytransparency (CONIKS implementation)
• https://github.com/facebook/akd (SEEMless implementation)
• https://github.com/Bren2010/katie (Merkle^2 implementation)

Agenda

• Problem statement and use-cases
• Proposed scope of work
• Presentation of current draft protocol
• Wrap-up

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

N/A