KEYTRANS@IETF119

Date/Time: 2024-03-20 00:00-01:30 CDT

Chairs: Shivan Sahib, Prachi Jain
Note-takers: Daniel Kahn Gillmor, Devon O'Brien

Agenda

Administrivia (10 minutes)

• Welcome
• Blue sheets / scribe selection / NOTE WELL
• Agenda revision

Presentations (80 mins)

• Architecture document (Brendan McMillion)

Minutes

Architecture document

Reviewed feedback from IETF 118. New draft addresses points raised.

• e.g. Impacts of GDPR and append-only ledgers

Overview of anonymous E2EE.

• Discussed Signal's use of enclaves and set intersection between
  contact list and user db.
• Can use cheaper anonymous channels (e.g. Tor) after initial step
• KT is an interactive protocol between client and server. Users can
  use anonymizing proxies for looking up their keys.
• There exists a monitoring burden to ensure proper log behavior.
• If user Alice is malicious, other users can monitor via anonymous
  channels.

Federation

• Ensure keys are namespaced properly
• Anonymizing proxies such as OTTP can mitigate privacy concerns

Lifecycle Management

• Log migration: when migrating, prepopulate new logs with existing
  data and store the old log's final root hash
• Pruning: size growth is an issue. CT handles this by temporally
  sharding logs and throwing away old logs when expired, but this
  doesn't work as well for KT.
• Unneeded KT data can be garbage collected. As logs age, the left
  half becomes increasingly unneeded and can eventually be pruned.

dkg: Once you've pruned information, how do users know that there wasn't
mischeif occurring in the now missing data?
Brendan: It's difficult to answer this question. If you still need data
for monitoring, that data cannot be deleted.

Kevi Lewi: Pruning a subtree seems to violate the apped-only properties

Brendan: You never lose the append-only property when you delete
subtrees. Data needed by auditors should not be deleted. Root hash still
covers deleted data, even if that data doesn't exist on disk anymore.

Compliance with Privacy Laws

• Unlike some other transparency designs, user data can be pruned but
  commitments to that data can be retained, and are anonymous wrt user
  data.
• All that's stored in a log is a commitment to a value, so data can
  be deleted without affecting append-only log property.

User Names

• Lookup keys will likely be stored in prefix trees.
• Can prune this tree as well, but prefixes are still left behind.
  This is probably OK because lookup keys are randomized with VRF.

Orie Steele: Trying to understand privacy properties around VRF and
salting messages going into log. What's the role of VRF here?
Brendan: VRF maps input bytes to output bytes, which are essentially
random unless you have the VRF proof. Shows uniqueness, correctness.
When removing things to e.g. comply with privacy laws, you delete the
input key and proof. Reduces to a problem similar to password cracking.
If VRF key is compromised, can do password cracking to recover data.

Privacy

• Discussed design tradeoffs across versions. Previous versions were
  better for service operators who care about hiding user numbers,
  current is better for individual users. Also impacts auditors'
  ability to tell whether an update changes/creates lookup keys.
• Upper limit on changes to a log is ~2^32.
• Current design also requires padding with ~100GB of fake data

Orie Steele: Does this only apply to scenarios when you're trying to
hide userbase size?
Brendan: Yes. If you don't care, this can be leaked and you don't need
to pad. E.g. WhatsApp reports userbase numbers via separate channels.
Old approach could leak additional info such as a user's update cadence;
new one obfuscates this.

Shivan Sahib: There aren't that many issues open on GitHub. Do folks in
the room have concerns/suggestions for the doc as-is? If so, this is a
good time to raise those issues. We would like to see a protocol
document start soon, before architecture document gets published. A
protocol document would address some of the vagueness/ambiguity in
architecture doc.

Felix Linker: Ready to work on protocol design and willing to help.

no one in room coming to the mic to answer question about starting work
on a protocol doc. ~4 +1s in the chat for protocol doc

Paul Wouters: TZ and travel make it hard for some interested parties to
participate, please ask on the list and don't assume quiet in the room
means disinterest

Orie Steele: excited to start protocol work. The sooner we delve into
that, the sooner we can analyze privacy and security properties of the
overall system.

Kevin Lewi: Agreed with Orie.

Stephen Farrell: happy to review as well. How do we recover when a log
goes bad?

Brendan: if the log needs replacement, refer to my migration slides. if
the log just disappears, i don't know how we manage that.

If you still have the old log, and you can make read-only queries, it
should work to have the final root nodes.

Stephen: i'm just trying to see how this would have affected the OpenPGP
keyserver network failures.

Orie: it might depend on whether you can do reads. if write failures
happen that isn't a problem.

Stephen: we need to think about what to do when a KT log fails, part of
the lifecycle concerns.

Devon O'Brien: read-only mirroring might be a solution for other
systems, but it wouldn't work for KT.

Brendan: structurally, the KT operator might not be open to a read-only
mirror.

Shivan: is the existingn protocol document a good start?

Brendan: nope, enough changes in the architecture document mean we
probably have to start from scratch.

Prachi: can you figure out some way to get a group of authors together,
via the mailing list?

Roman: are you asking for a design team?

Prachi: let's ask for contributors on the mailing list. it might end up
being a design team, depending on how people respond.