Session Date/Time: 10 Nov 2023 08:30

keytrans

Summary

This was the first session of the keytrans working group at IETF 118. The session included a problem statement on key transparency, an architecture overview, and presentations on the security and privacy properties of key transparency. Key topics included adoption of the architecture document, privacy considerations related to key lookup, key rotation, and data deletion. The goal of achieving a standard to promote wider adoption of key transparency was discussed.

Key Discussion Points

Problem Statement: Key transparency aims to solve the problem of insecure public key distribution in encrypted services. Current systems rely on trusting the service provider, which undermines the purpose of encryption.
Architecture Document Adoption: The working group discussed adopting the architecture document, which defines terminology, roles, and interactions within a key transparency system. Concerns were raised about clarifying requirements, particularly around security and privacy guarantees for different deployment modes.
Key Rotation: Recording key rotation events for JWK and similar keys was discussed as a potential application of key transparency.
Privacy Considerations:
- Privacy of key holders and those looking up keys were discussed. The potential for key transparency services to build a social graph based on lookup patterns was raised.
- The scope of privacy requirements, including protecting the privacy of those looking up keys in addition to the key holders.
- Potential privacy leakages concerning dissemination of tree heads, VRF key compromise, update history, and client queries.
Deployment Models: Contact monitoring, third-party auditing, and third-party management deployment modes were presented. Discussion centered on the isomorphic security and privacy features across deployment models, and the advantages and disadvantages.
Immediate Updates: The working group discussed whether to require immediate updates to the log or allow for interim inclusion proofs (like SCTs in certificate transparency). A concern was raised that requiring immediate updates might make the protocol too restrictive.
Linearizability: The need for clients to maintain state (tree head) to ensure a linearizable view of the log was discussed. Some participants expressed concern that requiring clients to maintain state might limit adoption.
Lifecycle Management: The need to specify a mechanism for migrating from one log to another and how to handle log failures or unavailability was raised.
Data Deletion: The handling of legally mandated data deletion and compelled deletion of user data without breaking proofs was discussed.
Anonymity: Support for sealed sender/anonymous communication was mentioned as something potentially missing.
Relationship Between Data and Committing to Chain: Confusion around the relationship between committing data itself versus committing the change to data was raised.

Decisions and Action Items

Action Item: Chairs to work with Brandon to address concerns regarding security and privacy considerations prior to adoption call for architecture document. Add new text to the privacy sections of the document.
Action Item: Add text to the architecture document about life cycle management, how federation would work, and privacy/legal compliance or compelled deletion of user data.

Next Steps

Take discussion of architecture document and feedback from meeting back to the mailing list.
Address outstanding concerns around privacy, security requirements, and handling of data deletion in the architecture document.
Call for adoption of the architecture document on the mailing list after addressing concerns.