Minutes IETF120: keytrans: Fri 22:30
minutes-120-keytrans-202407262230-00
Meeting Minutes | Key Transparency (keytrans) WG | |
---|---|---|
Date and time | 2024-07-26 22:30 | |
Title | Minutes IETF120: keytrans: Fri 22:30 | |
State | Active | |
Other versions | markdown | |
Last updated | 2024-07-30 |
minutes-120-keytrans-202407262230-00
KEYTRANS WG Agenda at IETF 120
Agenda (90 mins)
- Welcome, note taker, Note Well, chair updates (Chairs) - 10 mins.
Slides - Protocol draft discussion (Brendan McMillion) - 60 mins.
Slides - Contact monitoring and auditing modes (Esha Ghosh) - 15 mins.
Slides -
AOB and closing (5 mins)
-
Chairs welcome & agenda bashing
-
Protocol draft discussion & presentation (Brendan McMillion - BM)
- draft-keytrans-mcmillion-protocol overview
- Jonathan Hoyland (JH): can you check for non-existence of a key
with the same version? - BM: follows from how the binary search works
- Bengo Goering (BG): question about search path consistency
- JH (from floor) & BM: ... answer about how the search works
- BM continues presentation
- Yaron Sheffer (YS): do you want to ensure that the server is not
cheating and isn't giving different answer to different clients? - BM: the user can hold on to the last root hash and use it to
ensure consistency over time, also gossip with other clients to
ensure consistency - YS: what is the minimum effort needed to ensure consistency?
- BM: unclear
- Deb: solicit reviews from the WG!
-
Esha Ghosh (EG): presentation on client monitoring and 3rd party
auditing (part of the arch draft)- Felix Linker (FL): doesn't the client need to remember the key
history? - EG: client don't need to carry state but the user will need to
remember some things about their updates - FL: client state could help to automate this?
- EG: best if we can support stateless clients
- Ben Schwarz (BS): client need state to keep their key?
- EG: should be able to detect lost key state
- BS & EG continues discussion about the need for client state
- EG: security isn't compromised when state is lost - wo state you
can at least have detectability - Watson Ladd (WG): question the real-world usefulness for
stateless detectability - EG: ...
- Dennis Jacksom (DJ): there are usability issues that aren't
covered by this representation. need to look at the actual
usecases. - EG: agree
- JH: what is the usecase?
- EG: i lost my phone and somebody changed a key on my behalf
- EG: continues presentation - cost of covering both modes,
comparative analysis - FL: asks question about the v-factor from the slides... what
does this mean? - EG: explain difference between v & t
- BM: what persistent state exactly don't client need?
- EG: no need for a signed tree head or a key
- WL: why are the costs different?
- EG: the data structures are different
- FL: re BM question: what keys did you mean
- EG: the clients key
- EG: continues presentation on datastructure
- ... some clarifying discussion
- JH: you need to keep a hold on the tree head?
- FL: inaudible...
- JH: as long as you are only going to the transparency server it
can lie about my peers (? - Dennis Jackson (DJ): you need to talk to somebody who isn't the
attacker to detect an attack - EG: continues presentation on 3rd party auditing mode
- YS: question about the impact of the centralized architecture on
the threat model - how do you avoid getting lied to by the
server? - DJ: agree..
- FL: agree ... (mostly inaudible)
- Thibault Maunier (TM): integrity isn't a goal but consistency is
- EG: continues presentation (client monitoring mode slide)
- EG: question to WG: should we support both modes?
- FL: doesn't the current draft already support auditor monitor?
- EG: yes but not optimally and not wo keeping state
- FL & EG: discussion - FL argues that the current draft already
supports 3rd party auditors well enough. EG: claims key
searchers would be more efficient - WL & EG: clarifying discussion about the difference between the
two proposals wrt comparative search costs - BM & EG: optikc will be less efficient for some other modes than
3rd party auditing - a tradeoff - Shivan Sahib (SS) - chair: is there interest in these draft(s)
from the WG? - HannesT (HT): both proposals seem close to each other - can the
difference be quantified in absolut numbers? - EG: will link to papers with some research
- SS: any deployments?
- EG: similar to what whatsapp deployed
- FL: believes that the differences are not critically different
- EG & FL continues discussion about weather the proposals are
really different - BM: propose an offline discussion between the two proposals
- SS: chairs will facilitate
- Felix Linker (FL): doesn't the client need to remember the key
-
wrapup and done